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

Maintaining and updating an Access database on a remote location

P: n/a
I have developped an Access database with a lot of coding. The size of
the database without data is about 5 meg.
I am ready to copy the database to a client PC which already has a legal
version of Access installed.
1.I am used to work with software such has C++ which basically save the
program in many files but I notice that Access VBA save all data into a
one big file. Any way I can brake it in multiple files?
2. If I make a change in my office say on only one form, how can I save
it then import it into the client's application. I tried using the
export from the VBA editor but I am getting an error message saying that
I can't import the file when I try importing it within another Access
application.
Any help will be highly appreciated.
Thanks
ARobi

Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
There are a couple solutions to this issue, and it's been commented on
in the newsgroups recently, but here's a link to a Database Journal
article I wrote last month on the subject.

http://www.databasejournal.com/featu...le.php/3286111

--
Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast
"ARobi" <ar***@nospam.com> wrote ...
If I make a change in my office say on only one form, how can I save
it then import it into the client's application. I tried using the
export from the VBA editor but I am getting an error message saying that
I can't import the file when I try importing it within another Access
application.

Nov 12 '05 #2

P: n/a
What is common done in ms-access is to split the application into two parts.

the so called front end has all code, forms, reports.

the so called back end has JUST the data.

Further, right before you deploy the ms-access application (the front end),
you generally should create a mde. A mde is essentially a run-time version
of your application. All the source code is stripped out, as it a good deal
of extra junk. It is the compiled version of your application, and your
users cannot change this.

Now, your users can use the application, and you can work on a new front
end. When your new great version comes out, all you have to do is copy this
new file over the old file (and, of course, the data is safe in that back
end mdb). This is what we call x-copy development, and we had this for 10
years. People developing in the new .net stuff are now singing the praise of
x-copy development. Hence, you don't need any special install software to
update to a new version, but simply to give the user the new mde (hence the
term x-copy development!).

Of course, now that you have two parts, you have to:

a) make sure the end users ALWAYS places the data file in the same location
as when/where you developed the application (actually, it is where you
linked to must be the same).

b) Teach your users to use the linked table manager

c) Create some code to re-link for you in case the file paths/location will
be
different on the target pc.

As a developer, you will use the linked table manager often. (for example,
you can re-link to a test database to run some dangerous code. After your
are sure your code works, you can then re-link back to the production
database (another great reason to split you database). Anyway, you should
provide some code to re-link to the back end data if you plan to distribute
the application, and have to support users.

There is some code that all of use developers grab for fee from:

http://www.mvps.org/access/tables/tbl0009.htm

You can prove some GUI for the above..but at least the work is done!
(by the way, that above site is a gold mine http://www.mvps.org

That site code for virtually every question a developer with a brain has, or
will ask in the first year or two of development If you have a question, and
need some code to solve that question, chances are, it will be found at the
above site. So, think of all the code utilities and things you had to learn
in other environments....it is all in the above site on a silver
platter...have fun!).

For some more info on splitting, check out:

http://www.granite.ab.ca/access/splitapp.htm

http://www.microsoft.com/accessdev/a...ers/ba15_3.htm

And, for a free utility will automatically update the front end when you add
a new version to the server, c heck out:

http://www.granite.ab.ca/access/autofe.htm
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
No************@msn.com
http://www.attcanada.net/~kallal.msn

Nov 12 '05 #3

P: n/a
Hi Danny,
What is strange is to see how Access lacks in providing already built in
codes for a such important task...
The article you are refering to is quite interesting, but it assumes
that the client and the master databases are on the same network. This
is not my case; the client database is on a stand alone workstation.
The only way I can think of is to burn the database on a CD each time I
want to upgrade the database onto the client's workstation.
I will nevertheless study your codes and see how I can adapt it to my needs.
Thanks.

Danny J. Lesandrini a écrit:
There are a couple solutions to this issue, and it's been commented on
in the newsgroups recently, but here's a link to a Database Journal
article I wrote last month on the subject.

http://www.databasejournal.com/featu...le.php/3286111


Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.