ADODB.Recordset

[dhstein]

I have code:
Private Sub btnTest2_Click()
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset

rs.ActiveConnection = CurrentProject.Connection
rs.Source = "tblTest2"
rs.CursorType = adOpenDynamic
rs.LockType = adLockOptimistic

rs.Open


MsgBox "The table is open"

rs.Close

End Sub


I get the message "User-defined type not defined on the statement
Dim rs As ADODB.Recordset

Thanks for any help you can provide

 

[Dirk Goldgar]

I have code:
Private Sub btnTest2_Click()
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset

rs.ActiveConnection = CurrentProject.Connection
rs.Source = "tblTest2"
rs.CursorType = adOpenDynamic
rs.LockType = adLockOptimistic

rs.Open


MsgBox "The table is open"

rs.Close

End Sub


I get the message "User-defined type not defined on the statement
Dim rs As ADODB.Recordset

Thanks for any help you can provide

To use ADO, you need to have a reference set to the ActiveX Data Objects 2.x
Library. Do you?

Note that, for working with Access databases, the DAO (Data Access Objects)
library is more efficent and powerful than ADO. Is there any special reason
you're using ADO here?

 

[dhstein]

To use ADO, you need to have a reference set to the ActiveX Data Objects 2.x
Library. Do you?

Note that, for working with Access databases, the DAO (Data Access Objects)
library is more efficent and powerful than ADO. Is there any special reason
you're using ADO here?

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

Dirk,

Thanks for your response - that was the problem. As to the "why", I'm
trying to split a database and having many problems. So I thought part of it
was that ADODB would be better than DAO. So to test ADODB, I copied that
snippet from the Access "Bible" book to try it. Also that same book says to
use ADODB since Microsoft says it's "better" as a client-server development
tool.

 

[Dirk Goldgar]

Thanks for your response - that was the problem. As to the "why", I'm
trying to split a database and having many problems. So I thought part of
it
was that ADODB would be better than DAO. So to test ADODB, I copied that
snippet from the Access "Bible" book to try it. Also that same book says
to
use ADODB since Microsoft says it's "better" as a client-server
development
tool.

Microsoft has since changed its mind about that. ADO is better if you're
using an ADP (Access Data Project) and interacting directly with SQL Server.
But if you're working in an MDB (or ACCDB) with linked SQL Server tables,
you're better off using DAO for most purposes, with maybe a little ADO code
thrown in here and there. And if you're just linking to a Jet back-end,
there's no good reason to use ADO.

 

[Larry Linson]

Microsoft has since changed its mind about that.
ADO is better if you're using an ADP (Access Data
Project) and interacting directly with SQL Server.

Dirk, though I don't have the link here at hand, the Access team no longer
even recommends ADP-ADO for using Access with SQL Server. They now say that
Access - DAO - ODBC is the method of choice.

In what most of Microsoft considers "the real world of development"
(DotNet), classic ADO has been replaced by ADO.NET which uses neither the
same OLEdb underpinnings nor the same object model.

Larry Linson
Microsoft Office Access MVP

 

[Dirk Goldgar]

Dirk, though I don't have the link here at hand, the Access team no longer
even recommends ADP-ADO for using Access with SQL Server. They now say
that Access - DAO - ODBC is the method of choice.

I agree, Larry. I wasn't intending to say that MS was recommending ADPs;
just that if you *are* using ADPs, then ADO is the data access library to
use.

 

[a a r o n _ k e m p f]

do you have something in writing that says this?

it sounds like marketing BS to me.. the enemy of my enemy is not my
friend.