akeyes
asked on
ADO, RDO,DAO
I work in a very small shop, I am the only VB programmer in with RPG programmers, I was asked by the supervisor to define the difference, and advantages of ADO, RDO, DAO, my supervisor and I were unable to get a clear idea can any one help? I know and use DAO, but not the other methods.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
PS, if you start using ADO, its not going to be a lot different in a VB project than what you're used to with DAO. You have to get used to its funky connect property, but the learning curve coming from DAO is not steep.
ASKER
What about MS SQL Server which is better, advantages and disadvantages?
I strongly disagree with the note about RDO being a connection form for dBase, Paradox, FOxPro and DAO 'mostly for Access". DAO is for **ALL** ISAMs (Lotus123, Excel, Text, HTML, dBase3/4/5, FoxPro, Paradox, Outlook/Exchange) ... and Jet (Access is not a database type, it is a database management tools or "Front End" for Jet.
If you were concerned over the performance of RDO on ISms it might be due to you using the wrong tool for the job .. you should have beed using DAO. RDO is best for SQL Server.
ADO is a new technology with great potential but since it is so new it has a number of performance issues and some very limiting limitations.
If you want to see in easy examples the power and speed of DAO for ALL ISAMs, please visit: http://www.smithvoice.com/vbfun.htm You will see features of DAO tat most folks just don't know about , including a couple that MS says don't exist (lie full conversions from any ISAM to any other ISAM with no automation.
You will change your mind if you take a look.
Robert
If you were concerned over the performance of RDO on ISms it might be due to you using the wrong tool for the job .. you should have beed using DAO. RDO is best for SQL Server.
ADO is a new technology with great potential but since it is so new it has a number of performance issues and some very limiting limitations.
If you want to see in easy examples the power and speed of DAO for ALL ISAMs, please visit: http://www.smithvoice.com/vbfun.htm You will see features of DAO tat most folks just don't know about , including a couple that MS says don't exist (lie full conversions from any ISAM to any other ISAM with no automation.
You will change your mind if you take a look.
Robert
Robert,
Thanks for the tips. I'll chck out the site.
Thanks for the tips. I'll chck out the site.
Vettranger:
Hope you see something you like .. I'd like to see a spellchecker added to *this* site <g> Sorry for the typos in the last.
-Smith
Hope you see something you like .. I'd like to see a spellchecker added to *this* site <g> Sorry for the typos in the last.
-Smith
vbsmith,
I have an application where I'm exporting to a LOT of different DB types, and have NO control over what I have to export to, so this type of information always interests me. I checked out your "Export to Anything" document. The only question I have : Does that operation update the indices on this xBase databases?
I have an application where I'm exporting to a LOT of different DB types, and have NO control over what I have to export to, so this type of information always interests me. I checked out your "Export to Anything" document. The only question I have : Does that operation update the indices on this xBase databases?
You get automatic schema.ini files for html, lotus & text (either new inis or addendums to ones in the export path). For dBase/foxpro you get dbts if required ... I have yet to find a way to get automatic ndx/undx files, but I can't say that it can't be done somehow. After all, MS says that that line of code does not exist (it appears to be the underlying Jet code for "TransferDatabase" as it does exactly what that method does). Logically, since ndx files are created with Access's manual export then there has to be a way.
Caveat: xBase indexes are created with Jet 1,2 & 3 (through Access front-end exports in 1,2,95 & 97) however MS discontinued this feature of Access with Access2000. Worry over this was raised in the very first note posted to the Access2000 NG and MS replied: "We have decided to stop supporting the feature" which says to me that they have decided that they don't like it when you work with anything but MS products. Access2000 and Jet4 is really a step backwards. The good thing is that the Export To anything code still has the power under Jet4 (see also the extra source code under the smithvoice.com link for the Seattle VBDA meeting). eMail me from that site for further discussion if you like.
-Smith
Caveat: xBase indexes are created with Jet 1,2 & 3 (through Access front-end exports in 1,2,95 & 97) however MS discontinued this feature of Access with Access2000. Worry over this was raised in the very first note posted to the Access2000 NG and MS replied: "We have decided to stop supporting the feature" which says to me that they have decided that they don't like it when you work with anything but MS products. Access2000 and Jet4 is really a step backwards. The good thing is that the Export To anything code still has the power under Jet4 (see also the extra source code under the smithvoice.com link for the Seattle VBDA meeting). eMail me from that site for further discussion if you like.
-Smith
The above pointer is true to a point. DAO is still a viable tool for workgroup-level (multiuers) ISAMs. 100 concurent users? No, but DAO against JET makes the cut for a typical workgroup of up to 10 or so concurrent users and where any table holds less than a hundred thousand records *and* where the client does not want to pay the price of SQLServer (many simply do not want SQLServer and you can't fight them on it).
The point is, however, that if your project is of the Jet level (as most really are) then using DAO and taking advantage of it's ability to export/import any ISAM on the fly (or using a non-Jet ISAM via DAO) gives greater flexibility than RDO and with far more acceptable performance than the current version of ADO. Not to mention that ADO does not do conversions at all.
The point is, however, that if your project is of the Jet level (as most really are) then using DAO and taking advantage of it's ability to export/import any ISAM on the fly (or using a non-Jet ISAM via DAO) gives greater flexibility than RDO and with far more acceptable performance than the current version of ADO. Not to mention that ADO does not do conversions at all.