Hi, I've seen many people in this forum talking about using ADO rather than DAO. I haven't used it up to now, so the following questions might look illiterate!

1. What is the advantage? Why ADO?
2. Is there a short way of converting DAO code into ADO?
3. Does ADO have a future?

Thanks in advance...

Murat

Here is my two cents...a small two cents.

If I'm working on MDB objects from within an MDB, the I prefer ADO. If I working in an MDB with recordsets from SQL Server, then I move to the realm of ADO. If I'm in VB and pulling recordsets from an MDB then I use ADO.

A database can have references to both. Gives you best of both worlds. Just remember to always use the class name when declaring variables.

Dim rstDAOTemp as DAO.Recordset
Dim rstADOTemp as ADODB.Recordset.

Hope this helps,
Mike

Sorry about that, I re-read the first line and it should read.

If I'm working on MDB objects from within and MDB then I prefer DAO..yes DAO not ADO.

Thanks,
Mike

Hi!

I have a similar situation. I inherited an old MS Access database that exclusively used DAO. I recently was asked to move it to a WAN. The WAN supports all my users from a server that is 10 miles away. I have no way of know the WAN architecture, but I think my users data goes to the server via a router/mux/T1. The application is required to be launched from the server do to security reasons ... ie. can't have a local front-end on the hard drive. To make a long story short, the application is "dog-slow".

Being a part-time VBA programmer, I haven't been afforded the time to move to ADO ... 6 months ago, I couldn't spell it ... now I need to be an expert.

I did some experiments on our WAN and found that data retrieval in our situation is 2 to 3 times faster with ADO.

Question: would anyone have an example of how one would use a Open_Form event to create an ADO Recordset and set the Form Recordsource to it? I am using MS-Access 2000. I am running into multiple examples of connection strings that refer to DSN, etc. I just want to connect to an Access back-end sitting on my server. I do not need to deal with passwords or anything. Do I need to explicitly list the back-end's filepath in the connection string? I thought I saw an example that used "ActiveConnection" as part of the Connection setup. How do the tables in the back-end that I have linked to via the Linked Table Manager figure in to this? Do I skip the Manager and explicitly link with VBA on start up?

If someone could help me clarify some misconceptions with example code, I would really appreciate it.

Thanks!


--- Tom

Hi,

Thanks for the suggestions, Dataman! Could you tell me why you still prefer DAO (not ADO) in .mdb VBA. Problematic or just traditional or difficult? :)

Murat

Murat,
  Here are some of the reasons I like to use DAO over ADO when working with MDB Objects.

   I find the object model for DAO more strutured and easier to use.

   For example to open a recordset in code
     Set rstDAOTemp = CurrentDB.OpenRecordSet("SELECT * FROM tblABC")
     Set rstADOTemp = CurrentProject.Connection.Execute("SELECT * FROM tblABC")
    I find the first one easier to read.

   To change the contents, SQL, of a QueryDef. I can do it with 4 lines of code....and I have found that DAO can be faster when working with DAO objects.

   Did you know that Access itself has a hidden reference to DAO, even version 2002. It makes sense...that's why you put a SQL statmeent directly into the row source property of a combo or list box.

   And probably the final reason is that I've been using Access for going on 13 years now, before DAO was even born.

   Although Microsoft is not enhancing DAO any longer (no new versions), they are still supporting it. It's up to SP8.

   I'm sure I didn't do this discussion justice. There are many more who would argue for and against. I guess some of it boils down to personal preference.

Hope this helps,
Mike aka Dataman

Tom,

   Is your backend constant? What I mean is if your backend doesn't move and the tables you are linking won't change, then use the linked table manager, but be sure to use the UNC, go to network neighborhood, to connect, not a mapped drive. This will let the frontend work from any machine or location as long as the executing person has permissions to the back end location.

   I try to stay away from DSN's...I go DSNless...very cool. I ran into too many problems with new machines where the DSN doesn't exist, etc. Before I went DSNless I wrote code, VBA to auto create the DSN's I needed....still used on a few database, but I prefer to go DSNless.

Hope this helps,
Mike

Thanks, Mike!

--- Tom


--- Tom

Hi, Mike,

Thanks for your thoughts. I do appreciate them.

Murat