--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@...> wrote:

>
> burmair wrote:
>
> >>>> ...In terms of performance, is it faster to do as much as
> >>>>> possible in a single transaction (or maybe a few "chunks"),
> >>>>> or is it essentially the same if each update is performed in
> >>>>> its own transaction?...
>
> [...]
>
> So, don't write transactions that take hours to complete, but
> don't put each change in its own transaction either. In fact,
> look at the logic of your application, and build transactions
> that transform the database from one logically consistent state
> to another.
>
> Good luck,
>
> Ann

Ann,

Thank you for a such a cogent reply. We're using the embedded server,
which I understand is the SuperServer engine. In our case, a single
step from one consistent state to another may involve many millions of
discreet updates. Our problem is precisely that a single transaction
may take a large amount of time (hours is conceivable) to complete,
and the question becomes, at what point do the risks outweigh the
benefits of atomicity (which is important but not critical to us,
since the "correct" state can always be regenerated very easily if
needed). What we've decided to do for now is just what you suggested,
more or less. Using the spreadsheet analogy, we're treating each
"column" as a transaction of several thousand updates, instead of a
transaction per cell, which is what we started with. I'll let you
know how it turns out.

Thanks again for the concise explanation. It's exactly what I was
looking for.

Tim