By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,290 Members | 1,666 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,290 IT Pros & Developers. It's quick & easy.

Distributing a split database: catch-22 on data MDB file location

P: n/a
I have an Access 2003 database application that I split into an
application component MDB file (i.e., forms, etc) and a data component
MDB file (i.e., tables, etc.). I used the 2003 developer extensions
Package Wizard program to create an installation package. (Note: I
included the Access 2003 runtime because the users of my application
don't have Access on their machines).

My problem is that when a user runes the installation program, although
it puts both MDB files in the installation directory (e.g., C:\program
files\xxxx), it insists that the data component MDB be in the same
directory as it was on my development machine. The catch-22 is that
although I wrote code in the app to allow the user to relink to the
data MDB in the install directory, they can't get to it because Access
won't let the app start because it can't find the data MDB file to
begin with.

As I was using the package wizard. I noticed I had the opportunity to
specify the install location of the data component MDB file, but I
don't want to hardcode "C:\program files\xxxx". Is there a way in the
package wizard to use an environment variable or something to specify a
relative install location, i.e., the install location specified by the
user?

Thanks

Jul 17 '06 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Bill wrote:
I have an Access 2003 database application that I split into an
application component MDB file (i.e., forms, etc) and a data component
MDB file (i.e., tables, etc.). I used the 2003 developer extensions
Package Wizard program to create an installation package. (Note: I
included the Access 2003 runtime because the users of my application
don't have Access on their machines).

My problem is that when a user runes the installation program,
although it puts both MDB files in the installation directory (e.g.,
C:\program files\xxxx), it insists that the data component MDB be in
the same directory as it was on my development machine. The catch-22
is that although I wrote code in the app to allow the user to relink
to the data MDB in the install directory, they can't get to it
because Access won't let the app start because it can't find the data
MDB file to begin with.
You need to have startup code that allows the user to relink the tables
BEFORE anything in your app actually tries to use the tables. This means
your startup form cannot be a bound one.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 17 '06 #2

P: n/a
I see --- I'm chagrined - it seem so obvious in hindsight, thanks!

,
Rick Brandt wrote:
Bill wrote:
I have an Access 2003 database application that I split into an
application component MDB file (i.e., forms, etc) and a data component
MDB file (i.e., tables, etc.). I used the 2003 developer extensions
Package Wizard program to create an installation package. (Note: I
included the Access 2003 runtime because the users of my application
don't have Access on their machines).

My problem is that when a user runes the installation program,
although it puts both MDB files in the installation directory (e.g.,
C:\program files\xxxx), it insists that the data component MDB be in
the same directory as it was on my development machine. The catch-22
is that although I wrote code in the app to allow the user to relink
to the data MDB in the install directory, they can't get to it
because Access won't let the app start because it can't find the data
MDB file to begin with.

You need to have startup code that allows the user to relink the tables
BEFORE anything in your app actually tries to use the tables. This means
your startup form cannot be a bound one.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com
Jul 17 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.