Relinking Backend with INI

  • Thread starter Thread starter ChipH
  • Start date Start date
C

ChipH

Very new to VBA, but need this bad.
Have looked all over WEB, but most relinkers either depend on the user
to supply path or depend on only one Back end.

People on different servers need to use the same client with their own
BE. Problem is that noone thought to set up consistant paths.

Would like to setup a routine so that new pushes of the client will be
able to read in an ini to set the links for the backends for that
instance of the client.

Thinking it would need to read the tablenames and path to .mdb that
has the table, then relink, itinerate until links done.

TIA for the loan of your incredible minds.
 
There's really no need to use an .INI file -- just a plain text file
containing the path and file name of the database (or names of databases,
for that matter) containing the tables. It need not contain the names of the
tables -- the application that is relinking should include those. If you do
choose to use an .INI file, search in the archives for the API to access
..INI's -- that was a carryover from Win 3.1 to 32-bit Windows. As far as I
know, it is still available in current versions of Windows for backward
compatibility.

Current versions of Access have a corresponding, but builtin, functionality
to GetSettings and SaveSettings that accesses the Windows Registry for
information specific to the particular application/database. You might want
to consider that, instead.

I don't know how you are going to handle the situation without the user (or
administrator) selecting the proper path and filename at least one time.
Then it could be saved into the text file, .INI, or Registry, from where it
would be accessed in the future. On the other hand, are you sure the users
are going to find it easier to make sure the text file or .INI is in the
proper place than to locate the back end?

Larry Linson
Microsoft Access MVP
 
GetSetting and SaveSetting are all you really need. The user will need to
locate the file once (the first time they use it)...after that, your app
should look at the path specified in registry via GetSetting and relink to
that file.

'Air stub code
varPath = GetSetting("Your App Name","FilePath")

If Len(varPath) Then
Relink varPath 'Need error handler if varPath is invalid or does not
contain expect tables
Else
varPath = FindFile()
Relink varPath
End If

SaveSetting "Your App Name","FilePath",varPath
 
The trouble is, they go in that ridiculous area of the registry! ("User VBA
settings" or whatever it is). When two apps use the same names - boom! A
classic example of a good idea (providing inbuilt registry access
functions), with a hopeless implementation :-(

Cheers,
TC
 
I've seen very few apps that actually write in that location (especially
Access apps)....and fewer yet that have the same name. If your app has a
short name...you might have something to worry about, but most times not.
 
Very new to VBA, but need this bad.
Have looked all over WEB, but most relinkers either depend on the user
to supply path or depend on only one Back end.

Thank you so much, all of you for your help!

Now if I can just learn enough VBA to implement it.

My idea to put it in an INI file was to send an INI out to the
clients, based on the setup of their network.

I have 5 networks, all with a different path to where I can put the
data. The client app has 3 backends.Client goes on individuals pc.
Each network has 5 to 15 users. I know the paths for each network, and
wanted to make a file for each that would relink the client whenever a
new version of the client was loaded.

SYSop does not want to install link mananger on each machine for some
reason. Aside from that, I don't think the users would understand how
to use it anyways. On intial install they all kept opening I.E.
instead of windows explorer.
 
If you know the path already, couldn't you just include it in a table in the
frontend and then use that to build the connection string for the linked tables?
You could even include multiple records with the paths and test for existence
of the data file at each location and then use that path for connection OR
display a form with the choices that are valid.

You would need a startup procedure that checks the current connection value and
then check if it is valid, if not relink or reset the connection string on the
linked tables.
 
Back
Top