INI file reading, network vfs, auto refresh links

[mjdemaris]

Hey folks,

I am working on creating a method to automatically refresh the linked tables in our databases. I have read multiple posts regarding use of an .ini file.

What ini file are we talking about? What information is in there that is useful for database/file operations?

The way it is currently set up is this:
- both files (front end and back end) are on a network virtual drive
- to connect a new user to the database, I copy the FE to their PC, save as, enable...(read only permissions on network copy FE)
- when I update the FE, I copy the development file to the network, relink tables to the production BE, change the file versions in FE and BE to the next higher number
- so when the user opens up the FE, it checks for the version number, and if they don't match, copy the network FE to the desktop
- but, if I make some major changes to both files, then have to relink/refresh the links, I have to go to everyone's computer and copy it over, or trust that they can do it themselves.

If I could solve this to where I don't have to walk around the plant as much, it would be much easier to make changes and update files.

Thanks!

Plus, I want to give thanks for all the people who have helped me thus far in accomplishing the tasks above!

 

[MarkK]

What I most commonly do in this situation is 1) map a drive on the user's machine to the folder that contains the BE, and then 2) configure the FE to link to the BE file on the mapped drive. This way the BE is ALWAYS located at, say, Z:\data_be.mdb, and you NEVER have to muck around with re-linking the tables.

This also makes it much easier to swap out the BE, or simulate your BE in a development environment simply by remapping the drive.

Hope this helps,

 

[mjdemaris]

Are you saying that you develop in the same folder as the back end, or that you develop while linked to the back end?

I am not sure how the network drive is mapped here. We have a server, and on it are multiple virtual machines. Essentially, the Z:\ drive is a virtual disc on a virtual file system. I have tried getting the network share address, (i.e. \\server\shared folder), but that does not work. I have to address the drive as Z:\.

Unfortunately, not all programs can see these virtual drives. (That doesn't affect this, though. Just happened to throw that out there.)

Anyway, if I look at the drive/disc in explorer, I see a name:

everyone_blahblah(\\blahblbah) and under it
(G

So, the FE is linked via G:\folder1\folder2\database\backend.accdb

And every time I swap out FE or BE, I have to relink the tables. Well, I don't know about swapping out the BE, the only times I did that I also had an FE to go with it.

 

[MarkK]

Your BE is typically on a network share with a path like . . .

\\servername\folder1\folder2\database.mdb

In Windows, if you map, say, drive Q:\ to this path . . .

\\servername\folder1\folder2\

then in your FE, you can link to the BE at . . .

Q:\database.mdb

If you also have a Q:\ drive mapped to the BE in your development environment, then when you deploy --> NOTHING CHANGES, and you don't have to re-link your tables.

Makes sense?

 

[gemma-the-husky]

personally, I think trying to ensure the same mapping on different systems is a bit restrictive.

the path of a linked access database table is stored in a tabledefs connect property.

it looks something like this

;database=path

for a local table, the .connect property is blank.


if you need to connect to a different back end, then you need code to examine all connected tables, and reset the connect string.

there are two methods. one is to change the connect string and refresh the link.
the other is to drop the link completely, and rebuild the connected table.

Personally, I use the second method.

it's worth having a utility to do this in your "code library". There are lots of examples of back-end relinking.