Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
DAO vs. ADO?
- Thread starter Lamprey79
- Start date
yetanotherjo
Technical User
I don't have any tech info, but I have found ADO to be quicker and more stable when I've upgraded existing modules. I've only used it to link to SQL Server data sources so far though.
Two facts about DAO
- when working with mdb's the form recordset of all versions, is DAO, so you'll need some DAO anyway
- DAO, since it is native to Jet, is faster than ADO on most operations invloving Jet (access databases/backends).
ADO is newer, and more flexible, and usually faster, when connecting to other databases, though I don't know which is fastest on linked tables to SQL server. Lot of serious developers have never bothered to switch to ADO even if they work with SQL server backends.
Since DAO is deprecated, there wont be any new versions of it (3.6 is the final version), many has feared that it will die. One might say the death of DAO has been advertised since the release of Access 2000, so it shouldn't be news. I think, though, that DAO and ADO will coexist until Access is "DotNetIfied", at which time ADO.Net will replace them both.
A search here on DAO vs ADO, should provide more info and opinions.
Roy-Vidar
- when working with mdb's the form recordset of all versions, is DAO, so you'll need some DAO anyway
- DAO, since it is native to Jet, is faster than ADO on most operations invloving Jet (access databases/backends).
ADO is newer, and more flexible, and usually faster, when connecting to other databases, though I don't know which is fastest on linked tables to SQL server. Lot of serious developers have never bothered to switch to ADO even if they work with SQL server backends.
Since DAO is deprecated, there wont be any new versions of it (3.6 is the final version), many has feared that it will die. One might say the death of DAO has been advertised since the release of Access 2000, so it shouldn't be news. I think, though, that DAO and ADO will coexist until Access is "DotNetIfied", at which time ADO.Net will replace them both.
A search here on DAO vs ADO, should provide more info and opinions.
Roy-Vidar
sard0nicpan
Programmer
Funny, I was just thinking about the very topic this morning when I was recoding some DAO to ADO in order to take advantage of some stored procedures on my sql server backend.
For my two cents on the topic, you are unlikely to see much of a performance difference in small to moderately sized dbs, even if the backend is on sql server. For these, I tend to still use DAO in order to avoid having several additional lines of code scripted for the ADO connection strings (lazy excuse, I'll own up to it).
However, for large databases you will see major differences, especially if you access stored procedures written on the server-side. I have one database that stores the locations of images scanned. There are now over 220,000 lines of location and indexing data stored across 8 tables. Running my queries through the Jet database engine just does not hack it anymore. The sql server stored procedures are a beautiful thing! No more locking up on the client side due to the fact that Access is taking up about 50-75% of my CPU while the power of sql server was ignored.
Anyway, given RoyVidar's statements regarding ADO.net, I do feel that I will gradually migrate to more ADO scripting so as not to be out of touch. DAO is certainly useful, and the fact that it is still widely in use is certain proof. However, as ADO evolves, the eventual obsolescence of DAO is certain.
For my two cents on the topic, you are unlikely to see much of a performance difference in small to moderately sized dbs, even if the backend is on sql server. For these, I tend to still use DAO in order to avoid having several additional lines of code scripted for the ADO connection strings (lazy excuse, I'll own up to it).
However, for large databases you will see major differences, especially if you access stored procedures written on the server-side. I have one database that stores the locations of images scanned. There are now over 220,000 lines of location and indexing data stored across 8 tables. Running my queries through the Jet database engine just does not hack it anymore. The sql server stored procedures are a beautiful thing! No more locking up on the client side due to the fact that Access is taking up about 50-75% of my CPU while the power of sql server was ignored.
Anyway, given RoyVidar's statements regarding ADO.net, I do feel that I will gradually migrate to more ADO scripting so as not to be out of touch. DAO is certainly useful, and the fact that it is still widely in use is certain proof. However, as ADO evolves, the eventual obsolescence of DAO is certain.
On a broader scale, it should be noted that Microsoft officially ended mainstream support for VB6 last Friday. They claim that support is only offered for 6 years from product release, and VB6 was released in January, 1999. Popular opinion though, is that it's a push towards getting developers to migrate to .Net.
Personally, I prefer the .Net platform over classic VB (actually I use C# if given the choice), and ASP.Net is awesome compared to classic ASP. Once you've built a project in .Net it's hard to come back to VB6.
Here's the Microsoft announcement (on ASP.Net Web page):
Product Family Life-Cycle Guidelines for Visual Basic 6.0
If you've been monitoring jobs lately, you know that .Net opportunities are abundant, while VB6 jobs are rare - unless they involve a VB6 migration to .Net...
VBSlammer
"You just have to know which screws to turn." - Professor Bob
Personally, I prefer the .Net platform over classic VB (actually I use C# if given the choice), and ASP.Net is awesome compared to classic ASP. Once you've built a project in .Net it's hard to come back to VB6.
Here's the Microsoft announcement (on ASP.Net Web page):
Product Family Life-Cycle Guidelines for Visual Basic 6.0
If you've been monitoring jobs lately, you know that .Net opportunities are abundant, while VB6 jobs are rare - unless they involve a VB6 migration to .Net...
VBSlammer
"You just have to know which screws to turn." - Professor Bob
- Status
Similar threads
- Locked
- Question
- Locked
- Question
