Updating Table Links on Install

[aaron.m.johnson]

I have an application which contains an Access database with linked
tables that point to another database within the application. The
problem I have is that when the user installs the application, I need
to update the table links so that the paths are correct for the install
directory. Is there an easy way to accomplish this?

I'd really like to avoid duplicating the data in the linked tables, but
if updating the links is too much work, I may just do that.

[Larry Linson]

<aa*************@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...

>I have an application which contains an Access database with linked
tables that point to another database within the application. The
problem I have is that when the user installs the application, I need
to update the table links so that the paths are correct for the install
directory. Is there an easy way to accomplish this?

I'd really like to avoid duplicating the data in the linked tables, but
if updating the links is too much work, I may just do that.

The Developer Solutions sample database (see
http://support.microsoft.com/kb/248674/en-us in the Microsoft Knowledge Base
for information on the free download) has sample code for relinking tables
at startup.

Alternatively, the article at http://support.microsoft.com/kb/248674/en-us
tell you how to let the user use the Windows Common Dialog to choose a file
(the backend database) and you can create a TableDef with the link for each
table.

I use an approach very similar to the one in Developer Solutions that I
created prior to that sample database being available. It hasn't changed
much since the 16-bit Access 2.0 for which I initially created it.

Larry Linson
Microsoft Access MVP

[aaron.m.johnson]

Larry Linson wrote:

<aa*************@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...

I have an application which contains an Access database with linked
tables that point to another database within the application. The
problem I have is that when the user installs the application, I need
to update the table links so that the paths are correct for the install
directory. Is there an easy way to accomplish this?

I'd really like to avoid duplicating the data in the linked tables, but
if updating the links is too much work, I may just do that.

The Developer Solutions sample database (see
http://support.microsoft.com/kb/248674/en-us in the Microsoft Knowledge Base
for information on the free download) has sample code for relinking tables
at startup.

Alternatively, the article at http://support.microsoft.com/kb/248674/en-us
tell you how to let the user use the Windows Common Dialog to choose a file
(the backend database) and you can create a TableDef with the link for each
table.

I use an approach very similar to the one in Developer Solutions that I
created prior to that sample database being available. It hasn't changed
much since the 16-bit Access 2.0 for which I initially created it.

Larry Linson
Microsoft Access MVP

Thanks for the link. One question: will the automatic relinking
trigger when a database connection is made through ADO, or only if the
database is opened in Access?

[Larry Linson]

Table linking, as addressed in the sample database, is a matter of
definition of the tables, that is, the TableDefs Collection, in an MDB. The
code illustrated is VBA and DAO code. I can't imagine a good reason to use
ADO with a Jet database, because DAO is the native language of Jet. And, as
for me, I prefer to use DAO and link tables via ODBC even with server
databases.

The only advantage (if any) that I can see to using ADO, is using it with
another database, and without linking, via OLEDB (also called "an ADO data
provider"), so I just don't understand your follow-up question.

Someone else would have to discuss whether linked Tables makes any sense in
an ADO environment -- I certainly can't, as the only times I have used ADO
were some early practice testing and on projects done with an Access ADP
(aks "Access Project") that used ADO via OLEDB to access Microsoft SQL
Server directly. (And, as I have said before, I was unable to determine any
improvement in performance, and certainly none in ease of development with
the ADP - ADO - OLEDB - MS SQL Server environment. I'd work on such a DB
again if a customer alreeady had one and insisted, but I'd refer them to
another develper if they insisted on creating a new database in that
environment.

Larry Linson
Microsoft Access MVP
<aa*************@gmail.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

Larry Linson wrote:

><aa*************@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegr oups.com...

>I have an application which contains an Access database with linked
tables that point to another database within the application. The
problem I have is that when the user installs the application, I need
to update the table links so that the paths are correct for the install
directory. Is there an easy way to accomplish this?

I'd really like to avoid duplicating the data in the linked tables, but
if updating the links is too much work, I may just do that.

The Developer Solutions sample database (see
http://support.microsoft.com/kb/248674/en-us in the Microsoft Knowledge
Base
for information on the free download) has sample code for relinking
tables
at startup.

Alternatively, the article at
http://support.microsoft.com/kb/248674/en-us
tell you how to let the user use the Windows Common Dialog to choose a
file
(the backend database) and you can create a TableDef with the link for
each
table.

I use an approach very similar to the one in Developer Solutions that I
created prior to that sample database being available. It hasn't changed
much since the 16-bit Access 2.0 for which I initially created it.

Larry Linson
Microsoft Access MVP

Thanks for the link. One question: will the automatic relinking
trigger when a database connection is made through ADO, or only if the
database is opened in Access?

[aaron.m.johnson]

I probably should have noted up front that this isn't a native Access
app. I used ADO because when I started adding DAO components to my
VC++ application I got lovely deprecation warnings.

I'll probably just import the tables and deal with having two copies.
It's a pretty small amount of data so there's really no major issues
with that for now. It's just not elegant. But then, we write
applications with the databases we have, not the databases we might
want. ;)

Larry Linson wrote:

Table linking, as addressed in the sample database, is a matter of
definition of the tables, that is, the TableDefs Collection, in an MDB. The
code illustrated is VBA and DAO code. I can't imagine a good reason to use
ADO with a Jet database, because DAO is the native language of Jet. And, as
for me, I prefer to use DAO and link tables via ODBC even with server
databases.

The only advantage (if any) that I can see to using ADO, is using it with
another database, and without linking, via OLEDB (also called "an ADO data
provider"), so I just don't understand your follow-up question.

Someone else would have to discuss whether linked Tables makes any sense in
an ADO environment -- I certainly can't, as the only times I have used ADO
were some early practice testing and on projects done with an Access ADP
(aks "Access Project") that used ADO via OLEDB to access Microsoft SQL
Server directly. (And, as I have said before, I was unable to determine any
improvement in performance, and certainly none in ease of development with
the ADP - ADO - OLEDB - MS SQL Server environment. I'd work on such a DB
again if a customer alreeady had one and insisted, but I'd refer them to
another develper if they insisted on creating a new database in that
environment.

Larry Linson
Microsoft Access MVP
<aa*************@gmail.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...

Larry Linson wrote:

<aa*************@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...
I have an application which contains an Access database with linked
tables that point to another database within the application. The
problem I have is that when the user installs the application, I need
to update the table links so that the paths are correct for the install
directory. Is there an easy way to accomplish this?

I'd really like to avoid duplicating the data in the linked tables, but
if updating the links is too much work, I may just do that.

The Developer Solutions sample database (see
http://support.microsoft.com/kb/248674/en-us in the Microsoft Knowledge
Base
for information on the free download) has sample code for relinking
tables
at startup.

Alternatively, the article at
http://support.microsoft.com/kb/248674/en-us
tell you how to let the user use the Windows Common Dialog to choose a
file
(the backend database) and you can create a TableDef with the link for
each
table.

I use an approach very similar to the one in Developer Solutions that I
created prior to that sample database being available. It hasn't changed
much since the 16-bit Access 2.0 for which I initially created it.

Larry Linson
Microsoft Access MVP

Thanks for the link. One question: will the automatic relinking
trigger when a database connection is made through ADO, or only if the
database is opened in Access?

[David W. Fenton]

aa*************@gmail.com wrote in
news:11**********************@l12g2000cwl.googlegr oups.com:

I probably should have noted up front that this isn't a native
Access app.

Ya think?

The question doesn't even belong in this newsgroup, as you're not
using Access at all -- you're just using Jet.

And all answers regarding "linked tables" are, by definition,
Access-specific answers, and won't help you at all if you're not
actually using Access.

I really wish Microsoft would not use "Access database" and "Jet
database" interchangably.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/