Self Contained Access & Excel

[Emma Hope]

I wish to create a self contained suite containing an access database and
several excel spreadsheets that can be packaged into a folder and emailed to
our clients.

The client can save this 'suite' anywhere on their network or individual PC.
I have previously created spreadsheets that link to Excel using ODBC but i
have to specify the exact path for the database, is there a way to make the
ODBC understand the concept of 'the same path as the database wherever that
may be' also i wish to be able to open the spreadsheets from buttons in the
database, can anyone advise me of how to macro or code this concept to the
buttons?

Also i wish to make the database self-contained, i.e. the user should not be
able to access the 'F11', code etc, in fact, from the users perspective, i
don't want it to even look like a database (including not getting the
security messages on opening), is there a way of making the database into
something like an exe?

i have no control whatsoever over the external clients networks so cannot
make any changes to those, i am expecting the database to be unsplit and
unsecured in terms of access, i.e. no front end and back end and no access
user logins etc.

Finally and i think this is wishful thinking, i would like to be able to be
able to update some of the data tables when it is saved on their networks, is
there anyway to get the database to communicate with a copy on our server
over the internet?

Thanks for any help you can give.

 

[Pat Hartman \(MVP\)]

You can get close to what you want. Certainly you can zip the .mde (NOT
..mdb) and the spreadsheets into a single file that the client can unzip. If
you use the package and deployment wizard it creates .cab files for this
purpose and also gives the user a nice setup experience. The problem of
your database linking to the spreadsheets still remains. You can ship the
database with the .xls files unlinked. Your startup process can check for
links. If it finds none, it can prompt the client for a location (since you
aren't controlling where the database is stored, you can't anticipate the
path) and you can link the tables. Or, you can interagate Access to
determine where it was installed and use that information to build the path
to use for the Transfer Spreadsheet method. Here's an example of how to
find the application path:
MsgBox "The current database is located at " &
Application.CurrentProject.Path & "."

You will need to make custom menus and turn off access to the default menus.
Search for posts that detail how to do this. You also will need to disable
the shift-bypass key.

If the client will have access to your server, you can include links to
tables stored there. You will need to add code to run whatever update
queries you need at the appropriate time.