At 03:43 PM 3/29/2004, Edward Flick wrote:

>Just out of curiosity (I know I didn't stipulate this), will an update
>rollback to its previous state?

Unh, well, isn't that pretty much the definition of a
transaction? Something about "atomic" - succeeds or fails as a unit, if I
remember.

> 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?

It's about 110% more complicated, but the effect is the same. Committed
records, old record versions, and new as-yet uncommitted record versions
share the same page.

>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. Garabage collection (vacuuming to some) is automatic and continuous.

>| 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?

Nope. Not everything that's written is data. If your transaction
inventory page (for one) dies in the file cache, the database is going to
require major resuscitation.

Regards,


Ann

The problem with backing up stable blobs is that you spend a lot of time
(and space) creating new copies of exactly the same old stuff.