Question : Deploy Access Application with runtime and revise Table links - Inno - XP Developer - Iexpress

My Access FE will be deployed on a users PC. The BE will be deployed on the users server. I have no idea what directories will be assigned by the user. At this time with limuited resources Installshield is just to expensive unless the Software is deployed to many users (Just testing now). So I have tried using Inno, XP developer and iexpress.

They all have pieces of what I want to do but I don't see how to do it all with one product.

I need to set the table links in the FE to the directory the user sets up for the BE mde which has the Tables.
Also I need to have the installation include access runtime so the app will run no matter what version, if any, the user has installed on their pc.

Right now I can force the installation to be on the pc's C drive and force the directories to load correctly with a known directory name, also on th eC: drivre. But if the user installs on any other drive or installs on a server with a different map letter or does not have a c: drive defined, the app will not run. I do need to have the BE run on a server.

I am thinking that I need to store the chosen directory names in the pc's Registry and when the app first opens ( with a required acceptance of the EULA) then overwrite the TblDefs.Connect names in the FE DB.
I tried overwriting when the app was running and used a db.tbldefs.refresh but that did not work.
I have code in my app which deletes the links and relinks the BE, but it requires a password table which would be on the server and on startup would not be linked.

So, What I need is:
1. a sample script for Inno to add the access runtime.
2. script to add the selected directories to the registry.
3. script in inno to ask the user for a second directory for the BE DB's
4. script to add the BE Directory name to the registry
5. vb code to read the registry entries.

I have code in my app that will unlink and relink the tables.
Also have code that, on startup, checks to see if the tables are loaded.

Auto start runs a macro and I will need to write the code (module) that will check to see if the password table exists and if not then clean out all links and then link the tables to the registry names.

If you have done this or something similar how do you handle it?

Don

Answer : Deploy Access Application with runtime and revise Table links - Inno - XP Developer - Iexpress

We'll you've got about 6 different questions, but they are somewhat related ...

A lot of this depends on how the application will be used; if this is a single-user type system, then you can build your package to (a) install the "server" and store the directory that was used on the server and then (b) install the "workstation" component. Your workstation component would then rebuild the links on first startup.

if this is 2 different installs, then you'll have to either (a) have user intervention or (b) read/write the registry in yoru App. YOu can do that pretty easily with this code:

http://www.experts-exchange.com/Microsoft/Development/MS_Access/Q_21044170.html?query=registry+key&topics=39

This would be put in a Standard Module, and you'd call it from your app as needed.

There is apparently some info on dealing with Registry entries in the Inno help file; see this link:
http://www.jrsoftware.org/isfaq.php#dirnamereg

I'm not sure what you mean by a "password" table, but if you've rolled your own security system then you're on your own with this ...

Regarding the Runtime: you'd include the Runtime installation in with the Inno package and just call it as you would any other file. Most devs use the PDW to build the Runtime install, then package that along with their application and just call the .msi file in the Inno routine. In other words, don't try to use Inno to actually package the runtime, but instead let the PDW package it (or, if you're using the 07 runtime, just use the download) and deploy/run it with Inno.

I think you're going about the relink incorrectly. Your installation program really shouldn't do this, but instead your application would do this on "first run" (matter of fact, my apps do it every time they launch), and you'd use your code that destroys/creates links from there. This will require user intervention, of course, but there's little you can do about that.

                       
         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:

           
           
             '/assuming you've stored your tablenames in a local table, just open
'/a recordset, then move through that recordset:
 
dim dbs As DAO.Database
dim tdf As DAO.TableDef
 
Set dbs = CurrentDB
 
Do Until rst.EOF
  On Error Resume Next
  dbs.TableDefs.Delete rst("strTableName")
  dbs.TableDefs.Refresh
  Err.Clear
 
  Set tdf = dbs.CreateTableDef(rst("strTableName"))
  tdf.SourceTableName = rst("strSourceTable")
  tdf.Connect = ";DATABASE=" & rst("strSourceDatabase")
  dbs.TableDefs.Append tdf
  dbs.TableDefs.Refresh
Loop

           
         

Open in New Window

Select All