Invoking linked table manager with parameter

C

Charles Tam

From Access code, I would like to invoke the Linked Table Manager
(wztool80.att_Entry) with parameters, such that, it would only display the
tables that require re-connection. Any ideas?
 
M

Mark Burns

Douglas J. Steele said:
Why not just write your own code to do the relinking, rather than worrying
about trying to modify the LTM?

Check http://www.mvps.org/access/tables/tbl0009.htm at "The Access Web"
for
one approach.
Click to expand...

Douglas / Dev:

In the code at that link, I'm curious about something.
In his fGetLinkedTables function he scans the entire tabledefs
collection and only omits those tables with ODBC in the 1st 4 characters of
their connect string.
Why not use a ((tabledef.attributes = dbattachedtable) or
(tabledef.attributes = dbattachexclusive)) test to further pre-qualify the
list?
(I mean has experience show this to be unreliable or something?)
 
M

Mark Burns

Mark Burns said:
Douglas / Dev:

In the code at that link, I'm curious about something.
In his fGetLinkedTables function he scans the entire tabledefs
collection and only omits those tables with ODBC in the 1st 4 characters
of their connect string.
Why not use a ((tabledef.attributes = dbattachedtable) or
(tabledef.attributes = dbattachexclusive)) test to further pre-qualify the
list?
(I mean has experience show this to be unreliable or something?)
Click to expand...

Also, that code doesn't properly handle cases where the linked table name
has been changed in the front-end database, and this is a permissible
configuration. The collections really should store both the Name and the
SourceTableName to properly handle this condition.
 
D

Douglas J. Steele

Mark Burns said:
Also, that code doesn't properly handle cases where the linked table name
has been changed in the front-end database, and this is a permissible
configuration. The collections really should store both the Name and the
SourceTableName to properly handle this condition.
Click to expand...

I don't see any advantage to your first suggestion (checking the Attributes
property): that doesn't strike me as any more efficient than checking that
the Connect property is set.

You're correct about the second suggestion, but you'd only need to do that
in an application where you have renamed the table. Since you, as the
developer, will always know whether or not that's the case, it's a moot
point whether or not to build that capability into generic code.
 
M

Mark Burns

Douglas J. Steele said:
I don't see any advantage to your first suggestion (checking the
Attributes
property): that doesn't strike me as any more efficient than checking that
the Connect property is set.
Click to expand...

As I looked thru it a bit better I understood. The connect property isn't
set for non-linked tables, is it? so the .connect <> "" and the attribute
checking would be redundant given current (albeit undocumented) Access
9x/00/02/03(?) behavior.
You're correct about the second suggestion, but you'd only need to do that
in an application where you have renamed the table. Since you, as the
developer, will always know whether or not that's the case, it's a moot
point whether or not to build that capability into generic code.
Click to expand...

Actually, given good programming guidelines rule about not embedding
literals into code (unless ...) I'd have to disagree with you on that. So I
went ahead and implemented it.
 
D

Douglas J. Steele

Mark Burns said:
As I looked thru it a bit better I understood. The connect property isn't
set for non-linked tables, is it? so the .connect <> "" and the attribute
checking would be redundant given current (albeit undocumented) Access
9x/00/02/03(?) behavior.
Click to expand...


What's undocumented about it? Look up "Connect Property" in the Help file.
Actually, given good programming guidelines rule about not embedding
literals into code (unless ...) I'd have to disagree with you on that. So I
went ahead and implemented it.
Click to expand...

I don't understand your point. What embedded literal?

Remember that my initial post identified Dev's code as "one approach"
 
Top