Geoff & Ed,

Ok, I've been working on this some more and I have decided to do a couple of
things to accomplish the best of both.

First of all, I have enhanced the Gen_ID() routines to have a third
parameter:

ATrans: TIB_Transaction = TIB_Transaction(-1)

This parameter defaults to perform the old behavior that preserves the
performance and transaction efficiency as it was before. Of course, this
leaves the former risk to the server crashing and having the generator not
increment. You can pass in a NIL pointer as the transaction value to cause
it to make its own transaction handle and commit it. This will make the risk
go away but it will use up a transaction in the process. So, you can
individually control when you need a reliable generator value or not.

Second of all, since there is a fair amount of built-in generator value
handling, I have added a global variable that allows you to override things
such that all generator values acquired via IBO internal routines will use
the crash-proof method and ignore any transaction that was passed in.

IB_Schema.pas

var
// GenValueExec2: boolean = true;
GenValueCrashProof: boolean = false;

If you set this to true in your startup code somewhere then all generator
values will be retrieved in their own transaction and be reliable if a crash
happens.

Please let me know if this sounds like a good way to go.

Thanks,
Jason

> -----Original Message-----
> From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com] On
> Behalf Of Geoff Worboys
> Sent: Wednesday, November 09, 2011 5:55 PM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] Re: Generator not incrementing
>
> > 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