ADO programming

[Bill Morgan]

SCENARIO: I am using ADO to connect to a remote,
relational database to which Access 2000 will not allow me
to do a direct link (i.e., the remote db is not Access,
FoxPro, Excel, etc.). However, the remote db is an ADO
provider.

QUESTION 1: I want to be able to see the remote data in
datasheet view, as well as walk through the data via a
form - just as if the remote table were a local .mdb table
and the form was a bound form. In general terms, what is
the most widely accepted method of achieving this?

QUESTION 2: Can you briefly describe how I can most easily
achieve the effect of the standard navigation buttons on a
bound form? For example, should I rely on bookmarks and
public variables to achieve the effect of easily moving
back and forth through the recordset, using
the .MoveNext, .MovePrevious, etc. methods?

Thanks for your help.

 

[Albert D. Kallal]

SCENARIO: I am using ADO to connect to a remote,
relational database to which Access 2000 will not allow me
to do a direct link (i.e., the remote db is not Access,
FoxPro, Excel, etc.). However, the remote db is an ADO
provider.

I would think that ODBC is available. If you can't setup a DSN..then I
afraid you can't use the ms-access interface.

QUESTION 1: I want to be able to see the remote data in
datasheet view, as well as walk through the data via a
form - just as if the remote table were a local .mdb table
and the form was a bound form. In general terms, what is
the most widely accepted method of achieving this?

You setup a linked table. As mentioned, I don't know of what system you are
trying to connect to, but from as400 systems to IBM's uniVerse, to Raining
Data's D3 / Pick systems...they are complete different types of systems, and
in the case of IBM's Uni-verse and Pick..they are not even relational
database systems...yet you can connect to them with ms-access, and if you
setup a linked table..then ms-access can actually edit that data on a non
relation system. Truly amazing. However, you do have to setup a linked
table.

So, the most widely accept approach is to setup a linked table. If you can't
setup a linked table..then really..I would not bother using ms-access.

QUESTION 2: Can you briefly describe how I can most easily
achieve the effect of the standard navigation buttons on a
bound form?

Is the above a type-o? You mean to say a un-bound form..right? If you can't
setup a linked table...then you can't make a editable bound form with ADO.

For example, should I rely on bookmarks and
public variables to achieve the effect of easily moving
back and forth through the recordset, using
the .MoveNext, .MovePrevious, etc. methods?

If you are talking about un-bound forms..and the ONLY way to connect is to
use oleDB provider..then you should use VB here..and not ms-access. VB6 is
designed to work this way...but unfortunately..ms-access is not.

If you can't use and setup a linked table..then in effect you can't use
reports..and about 90% of ms-access features.

You are using the wrong tool unless you can get a linked table working...

 

[Bill Morgan]

Albert,

Thanks for your reply, which started me on the search to
learn more about ODBC drivers and how to acquire one that
may not come pre-installed with Access.

Question: Do you happen to know if Access, as is, will
link to a Unix database? If not, do you know whether or
not Unix ODBC drivers (32 bit, Level-1 compliant) are
available out there?

Thanks again ...

Bill Morgan

 

[Albert D. Kallal]

Albert,

Thanks for your reply, which started me on the search to
learn more about ODBC drivers and how to acquire one that
may not come pre-installed with Access.

Question: Do you happen to know if Access, as is, will
link to a Unix database? If not, do you know whether or
not Unix ODBC drivers (32 bit, Level-1 compliant) are
available out there?

Most UNIX database systems do come with some odbc drivers for windows. Of
the UNIX systems that come to mind like PostGres, MySql, Informix,
D3/raining data (and I sure others that don't come to my mind)..all do have
windows odbc drivers that can be used with ms-access. However, those
drivers will vary for each database vendor. So, in other words, each
database vendor needs to provide the odbc drivers..but most certainly do.

So, there is not "ONE" driver that fits all Unix databases...but I am hard
pressed to find one database vendor that does not have odbc support. So, the
ODBC driver will be part of the database vendors offering. I would be
surprised that the vendor offers oleDB support..but not odbc.

With odbc..then Excel..and Word can be used for example. (and, of course so
can ms-access). So, if a vendor does not provide a odbc driver..they
certainly leave out one of the most useful connections available...

 

[Bill Morgan]

Albert,

Now I get it. My memory object being what it is, I've
copied your responses to my "don't forget this stuff" file
of notepads. Thanks again for all your helpful advice.