> My sense is that there shouldn't be a client-side dependency
> on getting generator values for a long-running series of
> things. A good developer would always be able to avoid doing
> it this way. The call to the database to get the generator
> itself would be inefficient and worth avoiding so adding a
> transaction to that would not likely be a significant impact
> to a properly developed application. This is more or less
> intended for use in an interactive application where things
> are being worked with in small bits at a time.

I would remind you of the various performance code that has
been through here at times, code attempting to prove that
this or that other product is faster than IBO at inserting
umpteen thousands of rows. Now certainly the absolute best
performance in those situations may be to allow any generator
generation to take place in triggers at the server (or avoid
them altogether), but I've seen people here doing lots of
inserts into a buffered dataset, for example.

The big concern, it seems to me, is the potentially dramatic
increase in the use of transactions your suggested fix would
have and how this may effect sweep and other transaction age
issues, even just interpreting database stats.

> I could add a property CrashProofGeneratorCalls so that Ed
> could configure his application to be more robust and leave
> others with the default behavior. I could even make it be
> CrashProof when connected to an embedded server and otherwise
> leave it as it has always been.

Certainly this would be better, although I am still thinking
this is application specific, indeed I think it is probably
function specific, rather than embedded specific. A particular
function (that Ed can call in whatever this situation is where
the generator value matters outside the database) that does it
in a "crashproof" manner (the pedantic in me thinks "crash
resistant" ;-) seems a more appropriate solution to me ... but
then again I see from the archives that he already knows how to
achieve a varation that avoids the problem but wanted to avoid
changing his own code.

My logic is that most applications use a generator to generate
unique keys for database records. When used this way it does
not matter if the generator is not saved when the application
crashes because the transaction will be rolled back anyway and
so it's use of the generator has no consequence. I do not know
what Ed is doing that makes the generator important outside the
context of the last transaction that successfully committed
values from it, but it seems ununusal and so should be handled
separately to the more usual use of generators.

(Of course I could be overlooking something here, but
I imagine that Ed will correct me if that's the case.)

--
Geoff Worboys
Telesis Computing Pty Ltd