>> Just had time to read this bit, well, I couldn't have >> said it better. Probably many other improvements could >> be made on that driver. F.e. for me thos HB_ADORDD*() >> functions look a little strange in an RDD. They're >> needed to setup connection, and connection is stored >> in thread static data. I'm not sure this plays well >> with MT RDD features of Harbour. > > Many things can be done but it needs someone interested enough > in developing this code and with some deeper knowledge about RDD > internals. Looking at this code I'm find still new things which > should be implemented in different way. I can help with RDD code > but there is no chance that I can make anything with strict ADO > only code - it simply does not work in my Linux box ;-) > It's enough that I was working on OLE code without even single > runtime test.
That's the reason it got pulled from contrib. We need folks who are interested in this code. >> Plus one issue: Marek used to tell that data types >> aren't properly translated to Harbour types. > > Yes but it does not discards it. Many database drivers supports > only some subset of available field types. I.e. there is no other > DBF driver which can read all DBF fields supported by Harbour but > it does not mean that rest of xbase worls does not have usable > drivers ;-). In clean code things like new field types are usually > easy to introduce and can be done by users who will need them. Well, for me anything is fine :) It's up to real ADORDD users to fine tune all the details. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
