At 04:12 PM 17/11/2011, Geoff Worboys wrote:

>No, but I did read the code. There was no explicit commit,
>there was not even an insert against which to check whether
>a useful transaction was automatically rolled back.
>
>As Helen as reported there was a known bug in FB v1.5.0,
>fixed in v1.5.1, that could have caused the problem you
>are seeing, but assuming you are using a fixed version of
>FB (the supplied DLL was v1.5.6) then the expected results
>should be as I described.
>
>Write a demo that actually attempts to prove what you claim
>(that in v1.5.6 a committed transaction will not also save
>the generators it as used) and I will try it out.

As far as I have understood this tortuous thread, the problem was that the values of the generators appeared to have rolled back when the application crashed.

Now, the "client side" doesn't have anything to do with the generators. It's the server side that increments generators, in its own transaction. It makes no difference whether the client rolls back work or commits it, the generator never rolls back.

There's a page-flushing problem here: the crusty old Windows problem of it not flushing its own cache to disk until a file closes. So, if Ed is not configuring firebird.conf to force regular flushes, then, because the embedded server is running in the same application space as the app, crashing the application also crashes the embedded server and the flush simply doesn't happen.

Hence, though it appears the generator got rolled back, what really happened is that the database file didn't get closed so the generator page never got flushed to disk. Next time the database file is opened, whether by an embedded server or a full server, it's in the same state as it was when the previous (crashed) connection started.

That's the theory, anyway.

Helen