-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
Thanks for the quick reply Ann. Professional and informative as always,
you guys are why I like and always recommend this project ;-).

| There is no "mid commit". A commit is an atomic operation, consisting of
| the physical write of a single page containing the transaction
| state. Before that page is written, all pages that the transaction
changed
| have been written to disk. The on-disk representation is such that
change
| written by a transaction that rolls back, or dies in some mishap, are
| recognizable and will be removed by subsequent users.

Just out of curiosity (I know I didn't stipulate this), will an update
rollback to its previous state? Am I to assume that when I update a
record, it puts the update on a different page from the original, and
after the transaction is committed, flags the original as unallocated?
I'm just assuming I understand the whole multigenerational thing ok.
Also, in order for these pieces of uncommitted data to be recognized as
free space do I have to run gfix?

| No. If you have forced write on, you should be able to unplug the server,
| replug it, and continue.

With forced writes off (not that I plan on doing this as I'm using the
embedded server), it should still provide the same level of consistency,
correct? In other words either way the transaction is going down the
tubes, but with forced writes off, it could just possibly be more than
one transaction down the tubes, right?

|>As far as I am concerned as long as the database (worst case) does not
|>get corrupted beyond repair by gfix, I am fine with storing images in
|>the database.
|
| The usual reason for storing images outside the database is sheer
database
| size which affects the ability to backup and restore the database.

As far as this application goes the data is an auxiliary for the images,
and the data would be worthless without the images. Is backing up a
database with images infeasible, or is it just not recommended for those
with images as secondary to the actual data? Thanks in advance.

Edward Flick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32)

iD8DBQFAaIphvWeCZ4RLdzYRAkaeAJ9liZLNzoc7b4Y3yDLnh1BKwS+IvQCfcP9g
vnqw5EyGhh+heYl8eKgM+M4=
=qKj8
-----END PGP SIGNATURE-----