Automatically create/refresh table links (All)

Topic

New Reply

Dear members of the board,
Helen Feddema discusses in her Access Archon Column #63 the programmatic creation of the required links to linked tables at the opening of a database. Now I wonder…
Instead of linking them in code one by one, why not use a table with source data info and loop through its records instead:
e.g. tsysSourceData =
TableName +
Description (could be added as property while linking) +
Format +
Database file +
Fields for further description +
Fields storing values for the parameters used in the code.
Optional: subfolder and/or full path field in case one would like to store the data sources in more than one subfolder and/or other locations.

As such you have less code (and more universal if combined with the table), you can use the table to describe/document the source data inside the application and it might (?) be more easily managable. On the other hand, their occurs maybe a minor slow-down…

Could you agree, or do you see other reasons why better (not) doing so?

Reply | Quote

Replies

We use a method similar to what you suggest to maintain the table links in our applications. The table we use includes the name of the table to be linked and the name of the primary key fields each in a separate field to handle multi-field keys. We do NOT store any location information in that table because the user is allowed to relink to a different database. The current link location is stored in another local table, where it is written whenever the user links to a different back end. We do store a value that indicates which type of file the table is found in, since we link to multiple files and distinguish between which one contains each table.

Reply | Quote

Thanks, Charlotte,
now I start wondering: why do you leave your users the opportunity to relink to a different database? Is this for allowing them to switch to, say, an archive table with the same structure? Or can the user just interfere in the (re)linking process as the source data locations might vary quiet unpredictably?

Reply | Quote

We send our front ends out without links. The user specifies the main database. The other are in the same folder as the application and the user has no control over that.

Reply | Quote

We send our front ends out without links. The user specifies the main database. The other are in the same folder as the application and the user has no control over that.

Reply | Quote

Thanks, Charlotte,
now I start wondering: why do you leave your users the opportunity to relink to a different database? Is this for allowing them to switch to, say, an archive table with the same structure? Or can the user just interfere in the (re)linking process as the source data locations might vary quiet unpredictably?

Reply | Quote

We use a method similar to what you suggest to maintain the table links in our applications. The table we use includes the name of the table to be linked and the name of the primary key fields each in a separate field to handle multi-field keys. We do NOT store any location information in that table because the user is allowed to relink to a different database. The current link location is stored in another local table, where it is written whenever the user links to a different back end. We do store a value that indicates which type of file the table is found in, since we link to multiple files and distinguish between which one contains each table.

Reply | Quote