Again why are we using DAO ? (1 Viewer)

[nIGHTmAYOR]

Ok as far as i understand DAO is history , it's VB 3 material which was replaced by ADO and now ADO.Net came to take place.
Now for my understanding MS Access VBA can handle all 3 Methodes of SQL execution (ADO , RUNSQL and DAO) so for my understanding since RUNSQL is an access Specific command it should handle calls faster than any of the other means and should be the command of choice , however others have noted that they wouldnt recommend RUNSQL because it would generate a confirmation message box (which can be disabled programaticaly by a couple of lines of codes and save heaps of syntax over the sum of an entire application!) which can be annoying to users.
Which leave us to the fact that we still can use ADO's simpler syntaxes and to catch up with modernization cycle. However I could notice that through-out the net most listed examples are wrote in DAO and have been inherited since back in 1995. Now would someone explain to me why are we heavily supporting this DAO dinasour and when are we going to catch up with modern world ?

 

[DJkarl]

When dealing with MS Access DAO offers certain things that ADO does not.

Check out this article
http://blogs.msdn.com/michkap/archive/2007/07/13/3849288.aspx

 

[nIGHTmAYOR]

in your article someone who posted a responce seemed to answer to all claims the article writer had that it made it seem that the writer wasnt professional enough in his research. Now now , apparently its all a case of heritage , nobody wants to enovate , just copy . However think about it from a new prespective , 1 day you will think about migrating , with only VB .net as the platform of choice , maybe then your scripts are going to be easily implimented as ADO doesnt have intermediate structures developed specificaly for jet engine

 

[wazz]

- native db (jet) connectivity
- linked tables
- multiple db connections
- dbDenyWrite (denies at the table level, not connection)
- dbDenyRead (sim)
- users and groups
- interface with outlook
- use from any vba environment, vb, foxpro, c++
- etc.

- points filched from 2003 vba programmer's reference (wrox) -

 

[nIGHTmAYOR]

wazz , please read posted link by djkarl to which a user answered to all you above claims.

 

[Rabbie]

wazz , please read posted link by djkarl to which a user answered to all you above claims.

I have read the article and there were valid points made on both sides. I see no problem n using DAO especially in DBs developed sometim ago. It's not a question of 1 bad 1 good. Both have their advantages and as long as the finished DB does the job what's the problem?

 

[nIGHTmAYOR]

1 day you will think about migrating , with only VB .net as the platform of choice , maybe then your scripts are going to be easily implimented as ADO doesnt have intermediate structures developed specificaly for jet engine

Thats my point .

So if migration isn't of an importance , why wouldnt users use RUNSQL and minimize their code ?

Like I'm saying , its an issue of heritage that nobody has researched.

 

[Rabbie]

Quote:
Originally Posted by nIGHTmAYOR
1 day you will think about migrating , with only VB .net as the platform of choice , maybe then your scripts are going to be easily implimented as ADO doesnt have intermediate structures developed specificaly for jet engine

Thats my point .

So if migration isn't of an importance , why wouldnt users use RUNSQL and minimize their code ?

Like I'm saying , its an issue of heritage that nobody has researched.

Glad to see you agree with your own points

 

[Banana]

Funnily enough, I've found DAO to be smaller in code footprint and quite straightforward to work whereas doing something similar with ADO requires me to hold several different objects to do one thing.

I'm sure that ADO is far superior choice for those developing in ASP.Net or something like that where they've spent more time and effort in optimizing for ADO performance. Likewise, Access/Jet is far more optimized when using DAO, and I've yet to see a serious effort from MS to use ADO or provide native object access via ADO as DAO does (in terms of TableDefs, QueryDefs).

It's the same reason why I chose ODBC over OLE DB for MySQL connectivity, even though Microsoft says OLE DB is the way future. It may be very well the case with SQL Server, but with MySQL, folks involved has chosen ODBC as the standard and thus spent more time/effort in optimizing the driver against ODBC than they did with OLE DB which has since been not developed/updated/maintained.

In Debian community, they have a novel solution which I think is quite relevant to this question- when deciding which piece of code should make it into the final release, they don't decide by committee (Ubuntu) or by one man (Slackware), but rather by looking at what piece is most popular among developer and use that.

Yes, there may be better piece of codes out there that may do the job 10x time faster, but performance isn't the only benchmark. There's robustness, flexibility and how you can use it among other numberless variances. Most importantly, the most used piece of code has far more peer reviews, refinements and development invested into it than the one-hit wonder which has been since discarded. As is the case with DAO in Access environment.

Rabbie is quite correct that there is nothing fundamentally wrong with using ADO, and I'm sure a sizable number of developers use ADO, more often for handling SQL Server backend. In their cases, ADOs was able to meet their needs better and that's great for them. In my case, I found DAO to make more sense because I work more within Access's native objects, and found it easier to run among with DAO.

 

[nIGHTmAYOR]

I learnt the Debian community solution the hard way and i understand you fully and as proof the word "Replace" comes to mind so now I get your takes against RUNSQL.

However now I can see that most are in favor of DAO for 3 reasons :
1-Wide Support (Heritage)
2-The thought that DAO is more optimized for jet (Not realy confirmed)
3-Syntax is betterly organized (O.K..)

V.S

ADO 2 reasons :
1-Readyness for migration
2-Shareing resources of Visual Basic / Visual Basic.Net

hmm, Nothing further to comment.

 

[boblarson]

DAO is not dead, in fact it was reintroduced as a default in Access 2003 and is the default in Access 2007.

Pat Hartman has posted several things on this and this is one short one:
http://www.access-programmers.co.uk/forums/showpost.php?p=455820&postcount=3

 

[LPurvis]

Somewhat random comments... (bearing in mind that I actually like DAO and ADO equally!!)

>> DAO is history , it's VB 3 material
Why would you suppose that? It's old - sure, and was prevalent until VB5 surely. But at least it's advancing. That's more than can be said for ADO.

>> which was replaced by ADO
Never replaced. True MS wanted to push ADO over DAO in Access but that never happened and the decision was reversed. ADO's remit differed considerably from DAO's (which was always intrinsically Jet) - being so provider specific it has to cater for more - but not necessarily with finer detail.
(FWIW I fully accept and enjoy that many OLEDB provider Jet statements are supported via ADO that neither Access or DAO can provide).

>> and now ADO.Net came to take place
But isn't directly supported in Access.

>> RUNSQL is an access Specific command it should handle calls faster than any of the other means and should be the command of choice
Again - why would you generalise that as anything other than opinion?
Yes - there are times when RunSQL may have a slight edge - others not.
RunSQL is an method of an Access object yes. Why would that make it preferable?
Access is merely the development environment. That it has some internal integration with Jet doesn't mean that it's necessarily faster at executing such statements than either of the data access API's. Sometimes it will be.

What you cite as heritage DAO code can also be thought of as a wealth of pre-existing code examples and precidents.
That certainly isn't a case of nobody wanting to enovate, and just copy - but why can't people both use that which has gone before and inovate in other areas?

As ADO hasn't advanced in several years I don't see how moving to it is considered getting with the times. I equally don't see how it's particularly great preparation for migrating to ADO.NET - other than perhaps some familiarity with the principles of disconnected data. (There surely can't be many hardcore .NET developers using old school ADO instead of ADO.NET).

That DAO is often better optimised for Jet work is frequently verifiable.
(ADO is capable of advantage again - but it's less likely to occur).

Ultimately - I'm forced to agree with Jamie Collins. Why tout one as the method of choice. Both together are stronger than either one.