Ed,

> > 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.
>
> Trying not to be frustrated here--this has take a **long** time.
> Responses have been slow. I go with 3rd party products because the
> support is typically a lot better then going with the Delphi components.
> Questions are getting asked that have already been answered in this
> thread...

I do the best I can to prioritize my time and energies and I'm sorry if you
feel I was lacking in my level of attention.

> but lets focus on the issue.

Sounds good to me.

> FTR, I simply created an example where it reproduced a problem my
> customers are seeing. I am not exactly sure how they are producing it. I
> simply found a way to reproduce it and posted it. I need a fix. It has
> symptoms of being caused by FB and IBO--that is why I spent a few hours
> creating a demo app that reproduces the problem.

I've already made you a workaround for the bug that is actually in firebird.

If you don't commit the transaction that was used to process the statement
to get the incremented generator ID then for some reason when the server
would crash the database would be recovered in such a way that the generator
increments were lost. I think that is the area the Firebird developers need
to look. Rather than roll back a crashed transaction entirely, the generator
stuff should roll forward.

I consider this a bug in Firebird because generators are supposed to
function entirely outside of transaction control. Once that generator is
incremented and returns a new value it should remain permanent regardless of
whether or not the transaction used to process the statement was
committed/rolled back or not. That's why I say during crash recovery
anything to do with generators should roll forward instead of roll back.

Just recently I enhanced the Gen_ID() method to acquire generator values to
allow you to pass in a NIL reference to a parameter of type TIB_Transaction.
By passing in a NIL this tells the internal routine to start a fresh
transaction, acquire the generator value and then immediately commits the
transaction so that it is crash proof. I also added the global variable
GenValueCrashProof in the IB_Schema.pas unit so that you can force all
generator requests to be handled inside of a transaction to assure they are
all crash proof. This adds a level of inefficiency and uses more
transactions but you may want that level of robustness. I don't think
there's much more I can do for your situation.

Regards,
Jason