Copying Tables

[Bob Quintal]

I have a question. My database is split. I want a backup copy of
my tables in another database on a different machine. Should I
use transferdatabase to get the info into the backup copy or
should I link the backup copy tables to the original database?
What happens if the original databse gets corrupted? Can I get
the table info into the original databse easily?
Any help appreciated, I'm still a little confused on this issue.
Thanks
DS

The best answer to that is neither transferdatabase nor linking is a
real backup solution. Simply exit the application and copy the back
end to your archive area usaing Windows.

I prefer to also rename the file to add a datestamp in hte filename,
so that you can keep last night's backup, and the night before, and
before. Often corruption will only manifest itself several daya
after occurence.

If your primary backup gets trashed, you simply copy the most recent
uncorrupted backup from the archive over the corrupt .mdb

 

[DS]

I have a question. My database is split. I want a backup copy of my
tables in another database on a different machine. Should I use
transferdatabase to get the info into the backup copy or should I link
the backup copy tables to the original database? What happens if the
original databse gets corrupted? Can I get the table info into the
original databse easily?
Any help appreciated, I'm still a little confused on this issue.
Thanks
DS

 

[DS]

The best answer to that is neither transferdatabase nor linking is a
real backup solution. Simply exit the application and copy the back
end to your archive area usaing Windows.

I prefer to also rename the file to add a datestamp in hte filename,
so that you can keep last night's backup, and the night before, and
before. Often corruption will only manifest itself several daya
after occurence.

If your primary backup gets trashed, you simply copy the most recent
uncorrupted backup from the archive over the corrupt .mdb

Thanks Bob,
So that is interesting. "Corruption will only manifest itesl several
days after occurence." I never knew that. So you can be in truth
operating with a corrupt database. I'd like to know more about corruption.

The suggestion you gave is a good one, but the probem is that I want a
transaction by tranaction copy of my database so that I can return to
where I was before this happened. So, what options are there?
Thanks
DS

 

[Bob Quintal]

Thanks Bob,
So that is interesting. "Corruption will only manifest itesl
several days after occurence." I never knew that. So you can be
in truth operating with a corrupt database. I'd like to know more
about corruption.

Example: you have a record get corrupted on tuesday, and it only
gets detected when you run the weekly report on Friday There are
differing levels of corruption, some created by a glitch in the
computer, others are created by a user setting the wrong date into a
record.

The suggestion you gave is a good one, but the probem is that I
want a transaction by tranaction copy of my database so that I can
return to where I was before this happened. So, what options are
there? Thanks
DS

You're dealing with Access here, don't be too picky. If you have a
truly mission-critical application, you should use a dbms with
journalling, and automatic mirroring. These are a lot more expensive
than Access.

I'm not denigrating Access here, I believe that MS-Access is the
best you can buy in its price range, and better than much in higher
ranges. I'm just stating that it is not always the best solution.

 

[DS]

Example: you have a record get corrupted on tuesday, and it only
gets detected when you run the weekly report on Friday There are
differing levels of corruption, some created by a glitch in the
computer, others are created by a user setting the wrong date into a
record.




You're dealing with Access here, don't be too picky. If you have a
truly mission-critical application, you should use a dbms with
journalling, and automatic mirroring. These are a lot more expensive
than Access.

I'm not denigrating Access here, I believe that MS-Access is the
best you can buy in its price range, and better than much in higher
ranges. I'm just stating that it is not always the best solution.

I'm sure your right, but at this point I really like Access a lot and I
don't have the time at this time to learn another application. Most
people seem to be using VB6 with an Access back-end. So it looks like
they aren't using te better stuff either. I would at some point like to
use a true client/server but I heard the downside is that it needs a lot
of maintance, which my clients aren't prepared to do. So in the
meantime I'm trying to paste something together to protect the data up
to the last transaction.
Thanks
DS

 

[Bob Quintal]

I'm sure your right, but at this point I really like Access a lot
and I don't have the time at this time to learn another
application. Most people seem to be using VB6 with an Access
back-end. So it looks like they aren't using te better stuff
either. I would at some point like to use a true client/server
but I heard the downside is that it needs a lot of maintance,
which my clients aren't prepared to do. So in the meantime I'm
trying to paste something together to protect the data up to the
last transaction. Thanks
DS

You could link to two back ends and use unbound forms for all
inserts and edits, writing the data to each back end in a separate
SQL statement. But that will only give you redundancy of the
records, not an audit trail.

You could set up an audit trail back end, logging every edit of each
field, with a date/time stamp added
http://www.mvps.org/access/modules/mdl0021.htm
http://allenbrowne.com/AppAudit.html

How many transactions do you project being made daily?

 

[Bob Quintal]

About 100 to 150 transactions. Actually I'm leaning or can I say
inching towards that. I gess thats what I mean by redundancy. I
don't need an audit trail, although I will look into what you
suggested. Always willing to learn. My only concern is with
linking, that means the network connection will always be open if
the back-end is on a seperate machine. Will it leave me open to
corruptin? Should I link then unlink on each transaction? Will
that be really slow? Thanks for your input.
DS

Opening and closing connections is very slow across a network.
Corruption by the network is not usually a problem, most often
corruption is caused by user error. (exiting by task manager, typing
illegal character strings, pressing the DELETE key 7,000 times in a
row, etc)

 

[DS]

You could link to two back ends and use unbound forms for all
inserts and edits, writing the data to each back end in a separate
SQL statement. But that will only give you redundancy of the
records, not an audit trail.

You could set up an audit trail back end, logging every edit of each
field, with a date/time stamp added
http://www.mvps.org/access/modules/mdl0021.htm
http://allenbrowne.com/AppAudit.html

How many transactions do you project being made daily?

About 100 to 150 transactions. Actually I'm leaning or can I say
inching towards that. I gess thats what I mean by redundancy. I don't
need an audit trail, although I will look into what you suggested.
Always willing to learn. My only concern is with linking, that means
the network connection will always be open if the back-end is on a
seperate machine. Will it leave me open to corruptin? Should I link
then unlink on each transaction? Will that be really slow?
Thanks for your input.
DS

 

[DS]

Opening and closing connections is very slow across a network.
Corruption by the network is not usually a problem, most often
corruption is caused by user error. (exiting by task manager, typing
illegal character strings, pressing the DELETE key 7,000 times in a
row, etc)

So, it looks like I'll just link the tables. Since the user is not
typing anything in, just picking from lit I should be fairly safe...lso
they will be using a touch screen, no keyboard!
Thanks
DS