Re: DAO vs ADO
From: Lyle Fairfield (LookItUp_at_FFDBA.Com)
Date: 08/08/04
- Next message: Ed Warren: "Access 97 and Access 2003 runtime together"
- Previous message: Douglas J. Steele: "Re: Access 2.0 Conversion to Access 2003"
- In reply to: Albert D. Kallal: "Re: DAO vs ADO"
- Next in thread: Mary Chipman: "Re: DAO vs ADO"
- Reply: Mary Chipman: "Re: DAO vs ADO"
- Messages sorted by: [ date ] [ thread ]
Date: 8 Aug 2004 11:03:30 GMT
"Albert D. Kallal" <PleaseNOOOsPAMMkallal@msn.com> wrote in
news:ef7kRrRfEHA.3016@tk2msftngp13.phx.gbl:
> "Mary Chipman" <mchip@online.microsoft.com> wrote in message
> news:vaq9h0dvf65vpb9boi75c00bpo1cllk3ee@4ax.com...
>
>> The best rule of thumb to go by is: use DAO when working with local
>> Access/Jet objects, and ADO when working with SQL Server data.
>
> I agree with the above. ADO has much better sql server support
> (stored procedures support for example is better).
>
>> In the
>> case of DSN-less links, you are working with local Jet QueryDef
>> objects. The links contain only connection info and not the actual
>> tables, which makes DAO a good choice. If you were to create a
>> recordset in code, you'd want to use ADO since it would be going
>> against SQL Server to retrieve the data. Using DAO in this case would
>> add additional overhead by loading Jet, making it very inefficient.
>
> Loading JET, or loading the ado object model these days don't
> make much difference!
>
> Further, believe it or not, when you use a DSN less link, and use what
> is called ODBC direct, then actually only load the dao object model,
> and jet does not touch your code!
>
> I am not kidding here, and I repeat:
>
> JET DOES NOT get loaded, nor does jet even touch your sql
> that you pass to the server!!!
>
> Here is a code example for ODBC direct: (this is DAO!!)
>
>
> Dim strCon As String
> Dim rstRecords As DAO.Recordset
> Dim wrk1 As DAO.Workspace
> Dim MyCon As DAO.Connection
>
> Set wrk1 = DBEngine.CreateWorkspace("TestWorkSpace", "", "",
> dbUseODBC)
>
> strCon = "ODBC;driver={SQL Server};DSN=;" _
> & "SERVER=192.168.1.101;" _
> & "DATABASE=RidesSql;" _
> & "UID=SA;PWD=;OPTION=3;"
>
> Set MyCon = wrk1.OpenConnection("mycon", dbDriverNoPrompt, False,
> strCon)
>
> ' now, you have a regular connection, and can build a recordset as
> ' normal...
>
> Set rstRecords = MyCon.OpenRecordset("select * from tblJunk")
<snips>
Do tables, views, stored procedures and udfs appear in the database window
when such a connection is made from Access?
If, so can we double click on these objects to open their "contents" in
data*** view, and can we bind a form to them?
If so, is this paragraph from the
Microsoft® Jet Database Engine Programmer’s Guide!
(kind of an old book)
still applicable?
***** begin quote *****
Microsoft Access, which relies on Microsoft Jet for its database
functionality, has calls to Microsoft Jet written into its internal code,
and doesn’t call the DAO DLL except when Visual Basic code in a Microsoft
Access database calls DAO. In other words, when you display a table through
the Microsoft Access user interface, Microsoft Access calls Microsoft Jet
directly through hard-coded routines. When you open a table by using Visual
Basic code, Microsoft Access hands the request to the DAO component.
***** end quote *****
-- Lyle -- use iso date format: yyyy-mm-dd http://www.w3.org/QA/Tips/iso-date -- The e-mail address isn't, but you could use it to find one.
- Next message: Ed Warren: "Access 97 and Access 2003 runtime together"
- Previous message: Douglas J. Steele: "Re: Access 2.0 Conversion to Access 2003"
- In reply to: Albert D. Kallal: "Re: DAO vs ADO"
- Next in thread: Mary Chipman: "Re: DAO vs ADO"
- Reply: Mary Chipman: "Re: DAO vs ADO"
- Messages sorted by: [ date ] [ thread ]