> I must say that *I* expect the generator to be consistent, so
> if a number is allocated, and another client uses the same
> generator then it should not depend on 'something else'
> happening for the change to the generator to be remembered?
> I have always assumed that having accessed the generator,
> then that number is 'lost' end of story ... if that is not
> the case, then the fault is with Firebird? But having been
> stung several times in the past by windows cache problems,
> clearing up ANY crash causing action would be my first
> concern when the 'server' is on the same machine.

Bear in mind that the crash we are talking about is the server
crashing (just that the example is using embedded so that he
can crash the server by crashing the app).

Think of this from the perspective of the database. If, as in
most applications, a generator is only used to create unique
identifiers for records in the database, then since FB v1.5.1
the database will (should) see perfectly consistent generators
regardless of what the client does. If the server crashes then
any uncommitted work that may have relied on unsaved generators
will be rolled back anyway so, from the the perspective of the
database, that unsaved increment does not matter.

If however the application has used the generator value for
some non-database purpose then the loss of the generator could
be an issue (in which case simply committing any transaction
is enough to force FB to flush its generator pages).

Could Firebird flush the pages with every generator increment?
Probably, but you would want to measure the cost before going
down that path.

--
Geoff Worboys
Telesis Computing Pty Ltd