Backing up data

[thebiggermac via AccessMonster.com]

I have created a stand-alone, compiled database for my clients. The compiled
version does have basic data installed in the program already. So here is my
problem:

My client installs the program on his desktop computer and adds additional
data. He then decides to install the program on his laptop (the license
permits this). Now, how does he backup the data off his desktop and install
it to his laptop and vice versa?

The ideal way is to save the data to a floppy or zip drive and have the
database read the info. But how do I do that? My knowledge of VBA is
extremely, powerfully, limited. Did I mention that my knowledge of VBA is non-
existant? You get my drift.

This is also necessary in case my client has to reinstall the database thus
losing any information he entered. This restore option would be great.

I know it can be done, I just don't know how. Assistence please.

 

[Jerry Whittle]

Is it possible that your client will be using the database on a laptop AND
someone else will be using it on a computer at the same time? If so, you need
to check into replication. However, I don't know if replication will work on
the stand-alone version of Access.

If your client is the only one to use the database at any time, then he
should be able to copy the Back End .mdb file to his laptop and, then when
done, copy it back to the computer. It will be up to your client to have the
discipline to remember which computer has the most up-to-date database file.
This also assumes that you split the database into Front End and Back End
components. You did split the database, didn't you?

Possibly the best solution is to put the mdb files on a large flash drive (2
gb or bigger) and only use the database with this flash drive whether on the
computer or laptop. Of course flash drives get lost and can break easier than
the hard drive on a computer.

No matter what, frequent backups are always a very good thing.

 

[thebiggermac via AccessMonster.com]

Jerry, you asked if I split the database. No. There was no reason to. Only
one person will be using the program, and he, or she, will either access it
via a desktop or a laptop, or both. My desire is to backup and restore data
should it be necessary to upgrade computers, or transfer the data files from
a desktop to a laptop or vice versa.

Since the program is a compiled, runtime Access version, I am finding that
backing up ONLY the data with some simple mouse clicks is becoming a
nightmare. I harken to my Quicken program where I can backup the data to a
floppy and then restore that data should it be necessary. I can also load the
Quicken program on another machine and use the backup file to bring it up to
date. The concept Quicken employs should be able to work in Access as well.
In theory it SHOULD be a simple process. But reality is another matter.

What I have discovered is replication is not an attractive issue here. Maybe
not impossible but not the best solution either. Splitting the database
follows suit. Possible but not desirable. There has to be another option.

Appending files is probably the best way to go, but over-writing files is not
out of the question. The end user would be responsible for any lost data
using the over-write method. The key is make the process transparent and easy
for the end user. Inserting a floppy or zip drive is about the only thing the
user should have to do. However, accessing, saving and then importing the
saved data is where I am failing.

Any assistance and/or direction you can provide would be most helpful, as I
am lost here.

Gary

 

[Mr. B]

Jerry, you asked if I split the database. No. There was no reason to. Only
one person will be using the program, and he, or she, will either access it
via a desktop or a laptop, or both. My desire is to backup and restore data
should it be necessary to upgrade computers, or transfer the data files from
a desktop to a laptop or vice versa.

Since the program is a compiled, runtime Access version, I am finding that
backing up ONLY the data with some simple mouse clicks is becoming a
nightmare. I harken to my Quicken program where I can backup the data to a
floppy and then restore that data should it be necessary. I can also load the
Quicken program on another machine and use the backup file to bring it up to
date. The concept Quicken employs should be able to work in Access as well.
In theory it SHOULD be a simple process. But reality is another matter.

What I have discovered is replication is not an attractive issue here. Maybe
not impossible but not the best solution either. Splitting the database
follows suit. Possible but not desirable. There has to be another option.

Appending files is probably the best way to go, but over-writing files is not
out of the question. The end user would be responsible for any lost data
using the over-write method. The key is make the process transparent and easy
for the end user. Inserting a floppy or zip drive is about the only thing the
user should have to do. However, accessing, saving and then importing the
saved data is where I am failing.

Any assistance and/or direction you can provide would be most helpful, as I
am lost here.

Gary

Gary,

As has already been stated, the situation would be entirely different
if your user is going to be adding or modifying data at the same time
that someone else is adding or modifying data. However, you indicated
in your initial posting that this was just one user and that the user
wants to be able to access the data when using the application on a
laptop or when using a desktop.

If this is the case, then spliting the database is certainly the best
solution. By splitting the database you will have one file that is
the data. You can then have your user to simply move that one file
from the laptop to the desktop or from the desktop to the laptop. One
other option for the data would be to get a thumb drive and place the
BE data file on the thumb drive. Path the FE to look to the thumb
drive for its data. This way, all the use would have to to is to
unplug the thumb drive and move it to the other machine. This would
also insure that no one would acidentally over write data because
there would only be one data source, the BE data file.

Hope this helps,

Mr. B

 

[missinglinq via AccessMonster.com]

Maybe I'm missing something here, but if you only have one user go from
desktop to laptop and back again, why be concerned about only copying the
data? Why not simply copy the entire database?

 

[thebiggermac via AccessMonster.com]

Here is the situation: the database is written for the recreational boating
industry. High end yachts which sometimes translates into high end
maintenance costs. The database keeps track of these cost. Since the owner
could be cruising up and down the coast he would not have access to his
desktop computer, but he would have a laptop with him. If he should have to
perform maintenance on his vessel while on cruise he would enter that data
into the laptop. When he returned home he could then transfer the new data to
his desktop. In addition, a backup would be nice should his computer fail. He
could then just restore the data to a new computer. One computers or two
computers is not the issue, the issue is the ability to backup and restore
the data.

We had to ask the question: does the owner have ms access on his system? We
cannot assume that he does hence a runtime version is necessary. So the next
question is how do I make the backup and restore function seemless to the
user? And there in lies the challenge. So what is the best way to make this
happen?

I'm still open to suggestions.

Gary

 

[Mr. B]

Here is the situation: the database is written for the recreational boating
industry. High end yachts which sometimes translates into high end
maintenance costs. The database keeps track of these cost. Since the owner
could be cruising up and down the coast he would not have access to his
desktop computer, but he would have a laptop with him. If he should have to
perform maintenance on his vessel while on cruise he would enter that data
into the laptop. When he returned home he could then transfer the new data to
his desktop. In addition, a backup would be nice should his computer fail. He
could then just restore the data to a new computer. One computers or two
computers is not the issue, the issue is the ability to backup and restore
the data.

We had to ask the question: does the owner have ms access on his system? We
cannot assume that he does hence a runtime version is necessary. So the next
question is how do I make the backup and restore function seemless to the
user? And there in lies the challenge. So what is the best way to make this
happen?

I'm still open to suggestions.

Gary

Gary,

I guess I am confused. Either of the options that have been proposed
would be a viable solution to the issue as you describe it.

The database being a runtime version has no bearing on either
solution.

If you use the single file solution, you can have code in your
application that will simply copy the mdb file (runtime has nothing to
do with it) to a media with enough available capacity to hold it. You
would then simply have user to replace the mdb file on the next
computer that want to use it on.

If you used the split frontend/backend approach (again runtime has
nothing to do with it) then there would only be a data file (a
seperate mdb file, although much smaller) to have to deal with. In
this case you could have code in your application that would save the
data database file (the backend) to a media with enough room to hold
it. You could also have an option that the use could use that would
copy an existing (more recent) data file to the location where it can
be use by the current application.

I am curious as to the reason that you are not wanting to use one of
these methods. I have a commercial application that I have been
selling for several years and although the application is actually
written in VB the backend (the storage bucket for the application) is
an Access data file that only contains the tables. This application
has been utilizing this type of data storage and accessability for
years quite successfully. It actually simplifies the development,
deployment and backup processes.

Mr. B