Do you still use DAO ?

[IanS]

You may not agree but I think it would be interesting to know how many people are still using DAO every day ?

I have a number of legacy apps that still appear to work well on current 32 and 64-bit windows so I don't see any need to change.

What about you ?

I neglected to add an option for "Yes, I think it's fast and rock-solid and I'll keep using it till they force it out of my cold dead hands"

But maybe nobody would use that option - But tell me, what do you really think.

By the way - it's a secret poll, nobody will laugh at you no matter which way you vote.

[techgnome]

You're missing a few options. You want to know if people are still using but didn't provide a way to have people respond appropriately.
) Yes, but only under protest
) Yes, it's my party, I'll cry if I want to

Personally I haven't used DAO since it went out of style with Win95. It was good for what it was back in VB4. I wouldn't touch it in VB6, and even then I wouldn't touch VB6 if I can help it.

-tg

[si_the_geek]

You've also missed out the usual reason I've seen on the forums, which is "I didn't realise there was anything else".

[IanS]

You're missing a few options

I can think of a dozen options - everyone will have their own reason for (not) using it. So, maybe pick whichever option is nearest and then post something here - go on, flame me, I can take it

[Hack]

The last time I used DAO was...well,....I can't remember.

I think George Bush senior was president....if not him then Clinton.

That is about is close as I can narrow it down....I mean come on....you could probably still get to work on horseback. Do you?

[abhijit]

I have one app that still uses RDO. There's no budget to test it and convert it to ADO.

We should be moving away from VB6 too, but that's a separate issue.

I haven't used DAO since 1999.

[Pradeep1210]

My Ms-Access applications still use DAO

[Hack]

There's no budget to test it and convert it to ADO.

Thats what happened to my "convert all vb6/ado projects to vb.net/ado.net projects.

[IanS]

....you could probably still get to work on horseback. Do you?

A horse !! By jove, I think you got it. That doesn't sound like a bad idea at all.

So here's my choice - spend all day, every day opening my applications to remove DAO even though the applications are working just fine.

Or spend my days fishing, messing about in the garden and now - a new idea - a horse - that would keep me busy.

[si_the_geek]

Altering old projects in non-visible ways shouldn't be done unless there is an explicit need for it, or an abundance of time (perhaps as a learning experience).

For any new projects however, using DAO is a really bad idea due to the increase in the chances of problems with something that is so far out of support - whereas ADO is still current.

Using VB6 for new projects isn't a great idea either, but in terms of support etc it is about 8 years better than DAO.

[RhinoBull]

Bruce Almighty... Keep people from using DAO...


... enough said ...

[klen_]

What about you ?

Yes, I do. Because some users can run old applications.
All of these programs need support.
For example, sometimes changes need to be made in them.

[IanS]

Yes, I do. Because some users can run old applications.
All of these programs need support.
For example, sometimes changes need to be made in them.

As I see it DAO won't work in 64-bit - But my application is a 32-bit. I don't have a 'native' 64-bit application so it's irrelevant because anyone using my application on a 64-bit windows will of course be running it on WOW64 and dao is quite happy running on WOW64.

[si_the_geek]

The implication from Microsoft (at http://msdn.microsoft.com/en-us/libr...map_old_topic9 ) is that the problem is not specifically about running DAO itself in 64-bit mode, but running it on 64-bit versions of Windows at all (whether in WOW mode or not).

The few DAO/64-bit based threads I've seen have a similar implication, but as yet I am not aware of conclusive reproducible proof.


As I said, I wouldn't convert existing DAO apps to ADO just for the sake of it, but at the same time I also strongly recommend not using DAO for any new apps - because they are far more likely to have problems than the ADO equivalents.

[IanS]

The implication from Microsoft (at http://msdn.microsoft.com/en-us/libr...map_old_topic9 ) is that the problem is not specifically about running DAO itself in 64-bit mode, but running it on 64-bit versions of Windows at all (whether in WOW mode or not).

The few DAO/64-bit based threads I've seen have a similar implication, but as yet I am not aware of conclusive reproducible proof.


As I said, I wouldn't convert existing DAO apps to ADO just for the sake of it, but at the same time I also strongly recommend not using DAO for any new apps - because they are far more likely to have problems than the ADO equivalents.

Not wanting to flog a dead horse here but has anyone taken a look at Office 2010 ? Microsoft have been telling us for years to ditch Access and JET but if I'm not mistaken that's MS Access with a 64bit ACE engine in there which gives us 64bit JET - I don't know but isn't ACE just DAO with a different name.

[techgnome]

No... DAO is still based on the JET engine... which Access doesn't use anymore... Access uses the ACE Engine... which is why the connection string for ACE databases is different from the Jet ones.

Consider
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\mydatabase.mdb;User Id=admin;Password=;

Vs
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\myFolder\myAccess2007file.accdb;Persist Security Info=False;

And they are not interchangeable.

-tg

[si_the_geek]

Microsoft have been telling us for years to ditch Access and JET

Not really... they have been recommending to do any new development with newer/more-powerful alternatives, and only for about 2 or 3 years... as opposed to 12 years for DAO (the majority of which has been "actively replace it in existing apps when apt").

but if I'm not mistaken ...

You are mistaken on a two very significant points:

• ACE is not Jet, it is the replacement for it.
• Jet is not the same thing DAO, it is a database engine and driver/provider which can be used in conjunction with DAO.

Neither ACE nor Jet are specific to DAO, they can both be used by ADO etc (and I presume ACE can be used via DAO too, but I haven't checked).

[IanS]

I think this is one of those discussions like when people used to talk about "MS Access Databases" when what they really meant was "Jet Databases" (It just so happens that MS Access stored its data in a Jet database). Microsoft almost always refered to the database as a Jet database (not as an access database) In other words, Jet was not just a bunch of drivers. It's a whole database file system.

But, recently MS have dropped the name Jet and started calling it an MS Access Database and we therefore no longer need a Jet driver. We need an access database driver.

ACE is (so I've been told) 100% backward compatible with Jet4.

The latest database drivers for developers etc aren't part of windows but you can download them for 32 and 64 bit. I just downloaded and installed the 64bit drivers and hey ho, what do I see aceDAO.dll

[si_the_geek]

I just downloaded and installed the 64bit drivers and hey ho, what do I see aceDAO.dll

Just because there is a DAO driver for ACE (amongst all the various other things in that package) does not mean that DAO itself is safe.

[Hack]

I just downloaded and installed the 64bit drivers and hey ho, what do I see aceDAO.dll

Rotary dial phones are still available as well. Do you use those?

[Siddharth Rout]

Rotary dial phones are still available as well. Do you use those?

Though I don't use DAO but I have one of those Rotary dial phones. I dust it every day. It's a beautiful piece of art...

But then I also have gramophone...

[techgnome]

That's the one playback device I don't have... reel-to-reels, turntables, 8-track, I have... check that... I don't have a Gramaphone or a Victrola. I'm missing two... might have to correct that some day.

-tg

[IanS]

I found an article on MSDN talking about developing applications with C/C++ accessing MS Access 2007 databases. The article concludes with:-

Conclusion
This article describes Access, its ACE engine, and the mechanisms that are used to work with it,
regardless of whether you are writing native code. It shows how to develop Access solutions in
C/C++, and describes the data stack used by Access and some different components of the
engine. By using data access APIs such as DAO, OLE DB, ADO, or ODBC, you can continue to
create custom Access solutions for the most complex scenarios. Generally, as the default provider
for the ACE engine, the Direct DAO driver provides the most comprehensive native interface to
Access databases. It not only integrates well with the ACE Engine, it is also fast, stable and
backward-compatible with the earlier file formats. Therefore, DAO is the recommended data
access API when you develop your Access solutions.

That was written in relation to Access2007 databases - Now with access 2010 we have a 64bit set of drivers which includes a new dao driver for ace so I kind of feel that there's still life in dao.

http://msdn.microsoft.com/en-us/library/cc811599.aspx

[Pradeep1210]

I found an article on MSDN talking about developing applications with C/C++ accessing MS Access 2007 databases. The article concludes with:-

That was written in relation to Access2007 databases - Now with access 2010 we have a 64bit set of drivers which includes a new dao driver for ace so I kind of feel that there's still life in dao.

http://msdn.microsoft.com/en-us/library/cc811599.aspx

That's obvious since you are talking about C/C++