Database Life

[Guest]

Hi all,
First of all I'd like to thank every body who sent me a useful info,
I heared a lot that a databse made by Microsoft Access gets damaged
easily without any reasons, so I'm very worried about my databases and I'd
like to know whether it's correct or not ,and how to protect my database
against these damage
how many fields/records/tables/forms/macros....should I use as a maximum
number of objects to keep the database always working well
Best Regards

 

[Joseph Meehan]

Hi all,
First of all I'd like to thank every body who sent me a useful info,
I heared a lot that a databse made by Microsoft Access gets damaged
easily without any reasons, so I'm very worried about my databases
and I'd like to know whether it's correct or not ,and how to protect
my database against these damage
how many fields/records/tables/forms/macros....should I use as a
maximum number of objects to keep the database always working well
Best Regards

First any file of any kind can become damaged. Access, in part, I would
guess, due to the intense read, write to the file may be more subject to
damage than many other files.

While it is usually possible to spend some large $$$ to recover the
data, I suggest the most unused word in the computer world BACKUP.

You will need to figure out what might be the best solution for you. In
my commercial applications, they were on a mirror imaged drive had nightly
backups with monthly saves. The nightly backup was stored off line and off
site. Most applications would never need that kind of backup, but mine did.
I only needed a backup a few times and never more than the last day backup.

 

[(PeteCresswell)]

Per Pietro:

I heared a lot that a databse made by Microsoft Access gets damaged
easily without any reasons,

As far as I know there's always a reason. Maybe a bad NIC somewhere, a flaky
server.. whatever. But I guess that's moot and the only thing that matters is
that the DB is corrupted.

I do three things:
------------------------------------------------------------------------------
1) I split the application into front end and back end and always keep the back
end on the LAN where it gets backed up by the LAN backups.

2) I deploy the front end to each user's PC and keep the "Real" copy where only
I can get to it.

3) Depending on how paranoid I am in a given situation, I might put up a .BAT
file to keep maybe the last 100 days worth of the back end zipped up somewhere.
This because by the time the users realize something's corrupted it's possible
that the last good copy has fallen off of the edge of the LAN's backup cycle.

 

[Homer J Simpson]

3) Depending on how paranoid I am in a given situation, I might put up a
.BAT
file to keep maybe the last 100 days worth of the back end zipped up
somewhere.
This because by the time the users realize something's corrupted it's
possible
that the last good copy has fallen off of the edge of the LAN's backup
cycle.

Have you considered exporting the data as ASCII, compressing and backing up?
Even if you lose a few lines you still have most all of the data.

 

[(PeteCresswell)]

Per Homer J Simpson:

Have you considered exporting the data as ASCII, compressing and backing up?
Even if you lose a few lines you still have most all of the data.

Didn't occur to me at the time I guess because the size of the zipped back end
wasn't all that big. Also, I'd guess that would require a scheduled MS Access
routine to work and the outfit I did that particular job for would not allow MS
Access jobs to run on a file server - and they didn't have application servers.

 

[Brendan Reynolds]

FMS have a solution for this ...

http://www.fmsinc.com/products/Agent/index.html

I haven't personally tested it on a network. I have used it to do scheduled,
unattended export-to-text-then-compact-the-MDB tasks on my own PC, and it
worked well in that scenario.

 

[Tony Toews]

Have you considered exporting the data as ASCII, compressing and backing up?
Even if you lose a few lines you still have most all of the data.

But for the kind of systems I work with which have 20 or 150 tables
this would get quite cumbersome. Much better to just keep many copies
of the MDB.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm