Access Database Corruption
paul mitchell
can anyone give me some good tips for programming in VB that can help
mitigate or avoid Access database corruption. The app is a multi user with a
VB front end and a backend Access database. The app can be single user and
also the DB can sit on a server. We have big problems with corruption
especially when flaky networks are involved.
Thanks
Paul Mitchell
Hans-Joerg Karpenstein
one solution will be: "backup, backup, backup, ...)
With a flaky network there is no insurance and afaik no method available to
prevent db-corruption.
When there is a flaky network, you or your client should upgrade to a more
stable network
(better nics -I recommend 3Com-, switches -I recommend HP switches-, check
the cables and plugs-).
Manufacturer Recommendation result from experience)
--
HTH
Karpi
<fluctuat nec mergitur>
"paul mitchell" <pa...@nospam.fsnet.co.uk> schrieb im Newsbeitrag
news:b7hktl$n91$1...@news7.svr.pol.co.uk...
Bronwyn Wadsworth
The cause's have turned out to be many and varied - some of the causes have
been nic, switch.
But in other cases, I believe that there have been issues with software and
installation. Recently for a client, I have turned oplocks off on the
server to see what effect this will have - so far - the problem seems to
have gone (at the expense of slightly slower logon performance for users).
At another site I have apps served via Citrix, and moving all database users
to Citrix only access (rather than having some users direct) has also seen
database corruptions for these users disappear.
.
"paul mitchell" <pa...@nospam.fsnet.co.uk> wrote in message
news:b7hktl$n91$1...@news7.svr.pol.co.uk...
the Wiz
for some uses and relatively cheap for others. The Inno DB version supports
transactions and rollback to help prevent corruption from glitches. Just be
sure the server has a UPS.
"paul mitchell" <pa...@nospam.fsnet.co.uk> wrote:
More about me: http://thelabwiz.home.mindspring.com/
VB3 source code: http://thelabwiz.home.mindspring.com/vbsource.html
VB6 source code: http://thelabwiz.home.mindspring.com/vb6source.html
VB6 - MySQL how to: http://thelabwiz.home.mindspring.com/mysql.html
Fix the obvious to reply by email.
George Copeland
news:b7hktl$n91$1...@news7.svr.pol.co.uk...
> can anyone give me some good tips for programming in VB that can help
Access is not suitable for business critical apps. I hope you can migrate
to a more robust database, or you are SOL. Sorry.
JD
if someone is connected it causes corruption, maybe that is your problem?
Also there used to be an old crappy computer connected to the network and
after every time it logged into the database, it had got corrupted
(repairable always but still very annoying of course).
Hey I just thought of an idea...I currently keep all my data tables in a
single .mdb but maybe if each large table were kept in its own .mdb it would
be easier to backup. Anyone see a problem with keeping database connected
between several files rather than how most people have it in 2 pieces?
"paul mitchell" <pa...@nospam.fsnet.co.uk> wrote in message
news:b7hktl$n91$1...@news7.svr.pol.co.uk...
Peter Miller
On Wed, 16 Apr 2003 13:56:22 GMT, "JD" <bitb...@home.com> wrote in
comp.databases.ms-access:
>Hey I just thought of an idea...I currently keep all my data tables in a
>single .mdb but maybe if each large table were kept in its own .mdb it would
>be easier to backup. Anyone see a problem with keeping database connected
>between several files rather than how most people have it in 2 pieces?
There's no 'problem' directly, but several issues to consider.
Pros:
----
- corruption is less severe. While storing tables in separate files
provides no direct benefit vis-a-vis reducing corruption
occurrences,
if a table *does* become corrupted, it can not as easily escalate to
damaging the entire database as it could if everything was in one
file.
- avoiding Access/Jet db size limitations. The 2gb limit can be
surpassed by putting the larger tables in their own files. This
way, there is no absolute limit to how big a jet-based system can
become (although for practical purposes, it's rarely wise to
push beyond 2GB and insist on sticking with Jet).
- storage mgmt. By splitting tables into separate files, you can
manage storage more flexibly, taking advantage of multiple drives,
servers or other factors.
Cons:
----
- Referential integrity can not be enforced across files.
- Backup approaches need to take into account that just because
one file is free doesn't mean the others are not in use. This
isn't a big deal, but is worth considering.
Peter Miller
____________________________________________________________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.800.987.7716 1.619.839.3900
Tony Toews
>The app is a multi user with a
>VB front end and a backend Access database. The app can be single user and
>also the DB can sit on a server. We have big problems with corruption
>especially when flaky networks are involved.
FWIW visit the Corruptions page at my website for some tips on this. The most
important things to check first are OpLocks and use LDBView or Jet User Roster to
determine the work station causing the problem.
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