I see. Overall to me RDDSQL looks like a proper and common wrapper
implementation to our existing and not very much compatible
solutions:
HBPGSQL, HBMYSQL, HBFBIRD and HBODBC. And instead of direct
API calls and Harbour classes it makes this functionality accessible
through the existing Harbour db functions as an RDD.
Isn't it USRRDD an easier solution?
RDDSQL is written in C and only few developers here can master it
while if we create a set of USRRDD using the already existing C
interfaces, we'll potentially have more developers.
Also ARRAYRDD is a good candidate to manage "recordsets" and provide
"real time" data editing in browses so we'll have all the components
inside the same interface.
Would be good to know the performance hit using USRRDD
compared to native C RDDs. We should take into account
the extra layer it add, plus the fact that actuall RDD code
is programmed in .prg, which may be slower for some tasks.
IMO it's easily possible that well crafted C code can be
better quality than .prg code which is modified by multiple
developers through time. For such critical code as DB handling,
it's also an advantage that C is strong typed, so typos and
other omissions are less likely to stay in code.
At least that's my impression after working with/on our
several DB related source files.
It could also be an option to combine the two approaches.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
