Re: Do Transactions guard against corruption?

In Access version 2.0, it was common for databases to be left
in an indeterminate state, because databases idled in an
indeterminate state. That was in 1993.

This is no longer a problem. Access 95, 97, 2000,2002,2003,
2007 don't work that way. It is no longer common to find that
a database can't be opened because it was disconnected
without being closed correctly.

In Access 2000+, the LDB file is automatically deleted when
the last user disconnects. This means that any hanging locks
are deleted.

In Windows, file locks are automatically deleted sometime
after the user disconnects. This means that disconnected
users are automatically disconnected from MDB and LDB
files, allowing the LDB file to be automatically deleted,
allowing any hanging locks to be automatically deleted.

Have you ever had a database in a 'suspect' state?
Have you ever had hanging locks?

(david)



"JString" <JString@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F8794FF4-043A-4173-A709-0F1E1AB11492@xxxxxxxxxxxxxxxx
I think I probably should have made myself a little more clear about what I
meant by 'corruption'. Obviously corrupt data is bad data that Access
cannot
handle. However, it's my understanding that Access will mark a database
as
being 'suspect' if a connection is terminated prematurely, when a user is
manipulating data, even if there hasn't been an actual corruption of that
data. The end result is that all users will be locked out of the database
until someone recovers it.

So I definately get what you're saying about transactions having no
affect
on data integrity, BUT, can it guard against a database being placed in a
'suspect' state? It seems to me that if a transaction is never committed
(or
even rolled back) because of a system crash or whatever, Access shouldn't
do
this.

"Michel Walsh" wrote:

It seems you put in the same bag very different concepts such as data
integrity and database corruption, mainly when you speak of 'user error'.

If the user enter 23 when what should be entered is 32, that is a
mistake.
That is a user error and indeed, no transaction could help. A cup of
coffee,
having a validation number (CRC or otherwise) to be entered, having two
people entering the same data are all techniques that may help, but
transaction, no.

If the user fails to enter required data, or enter a not existing
reference,
that should be covered and trapped by table design (not null) or by data
integrity rule, etc.

Transactions have NEVER been designed as safeguard for those previous
kind
of 'user errors' in mind.

Sure, go immediately to the absurd, if its hard disk fails, then you are
likely to have to relay on having a RAID system, NOT on transaction, to
be
able to recover from these errors.

You can come with cases were transactions are useless, indeed.

BUT

the table structures are protected by lock, when you modify them, and
internally by a transaction (never got the error message that the
modification(s) could not be written because some data won't match a new
constraint you just added ?). But you won't use transaction "to protect
table structure" when no-one is modifying them, you use a back-up (or
scripts, ... or RAID).


Vanderghast, Access MVP



"david" <david@xxxxxxxxx> wrote in message
news:uUVqlk69IHA.4956@xxxxxxxxxxxxxxxxxxxxxxx
Most corruption is caused by user errors. For example,
deleting the wrong record. Or updating the wrong record.
Or Adding the wrong record.

That happens, and your data is wrong: it is no longer
true. It is corrupt.

Access no longer guards against your computer failing
or being turned off while you are using it (as it did in Access
2.0), so the only kind of corruption transactions now
prevent is the kind of corruption that occurs when you
have a programming or data error that halts a complex
sequence of actions, leaving some of your tables updated
and some of your tables not updated. This is database
corruption: your data is corrupt.

A transactional file system like Novell Netware could do
the same thing at the file system level, and it could be
used (not with Access) to prevent your data becoming
corrupted when the network went down or your computer
turned off.

Access also sometimes has problems with the structure
of the database becoming corrupted. Transactions are
not used by Access to protect the structure of the database.
If transactions were used to protect the structure of the
database, they would protect the structure of the database
during complex sequences of actions, just like you can
use them to protect your data during complex sequences
of actions.

Access still does not use transactions to protect the
database structure even if you use transactions to
protect your data during complex sequences of actions.

When you said 'corruption' you probably meant damage
to the database structure. No, transactions do not
prevent that, because transactions are not used by
Access at that level.

If you only have simple database actions, then transactions
do not do anything.

It is good to keep in mind that corruption of your
data by a network error is much less likely than
corruption of your data by user error. Transactions
do not prevent user error.

(david)







.

Relevant Pages

  • Re: Do Transactions guard against corruption?
    ... meant by 'corruption'. ... The end result is that all users will be locked out of the database ... So I definately get what you're saying about transactions having no affect ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... when the database is opened and closed. ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... integrity and database corruption, mainly when you speak of 'user error'. ... You can come with cases were transactions are useless, ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... get a message telling you that your database is locked and you can't ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
  • Re: Do Transactions guard against corruption?
    ... Have you ever had a database in a 'suspect' state? ... meant by 'corruption'. ... Transactions have NEVER been designed as safeguard for those previous ... not used by Access to protect the structure of the database. ...
    (microsoft.public.access.modulesdaovba)
Quantcast