Wrox Programmer Forums

Need to download code?

View our list of code downloads.

| FAQ | Members List | Search | Today's Posts | Mark Forums Read
Access VBA Discuss using VBA for Access programming.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access VBA section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old January 16th, 2004, 11:37 AM
Authorized User
 
Join Date: Jan 2004
Location: , , .
Posts: 13
Thanks: 0
Thanked 0 Times in 0 Posts
Default DAO / ADO?

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

Reply With Quote
  #2 (permalink)  
Old January 16th, 2004, 12:28 PM
Authorized User
 
Join Date: Jun 2003
Location: Glendale, AZ, USA.
Posts: 75
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #3 (permalink)  
Old January 16th, 2004, 12:29 PM
Authorized User
 
Join Date: Jun 2003
Location: Glendale, AZ, USA.
Posts: 75
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #4 (permalink)  
Old January 16th, 2004, 07:39 PM
Authorized User
Points: 306, Level: 6
Points: 306, Level: 6 Points: 306, Level: 6 Points: 306, Level: 6
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: , , .
Posts: 54
Thanks: 2
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #5 (permalink)  
Old January 17th, 2004, 03:20 AM
Authorized User
 
Join Date: Jan 2004
Location: , , .
Posts: 13
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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

Reply With Quote
  #6 (permalink)  
Old January 17th, 2004, 11:35 AM
Authorized User
 
Join Date: Jun 2003
Location: Glendale, AZ, USA.
Posts: 75
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #7 (permalink)  
Old January 17th, 2004, 11:40 AM
Authorized User
 
Join Date: Jun 2003
Location: Glendale, AZ, USA.
Posts: 75
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
Reply With Quote
  #8 (permalink)  
Old January 17th, 2004, 10:11 PM
Authorized User
Points: 306, Level: 6
Points: 306, Level: 6 Points: 306, Level: 6 Points: 306, Level: 6
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: , , .
Posts: 54
Thanks: 2
Thanked 0 Times in 0 Posts
Default

Thanks, Mike!

--- Tom


--- Tom
Reply With Quote
  #9 (permalink)  
Old January 18th, 2004, 07:39 AM
Authorized User
 
Join Date: Jan 2004
Location: , , .
Posts: 13
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi, Mike,

Thanks for your thoughts. I do appreciate them.

Murat

Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ADO or DAO knowledge76 Access VBA 3 October 12th, 2015 04:26 PM
DAO vs. ADO SerranoG Access VBA 11 December 5th, 2006 01:19 PM
ADO - DAO compatability petermat Access VBA 6 January 10th, 2006 06:06 PM
Dao to Ado vrtviral Access VBA 5 February 19th, 2005 11:13 AM
ADO vs DAO perrymans BOOK: Expert One-on-One Access Application Development 0 October 24th, 2004 11:36 PM



All times are GMT -4. The time now is 07:53 PM.


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.