At 09:33 AM 05-04-02 +0200, you wrote:

>Hello Frank,
>
>f> As Set pointed out, you need to know the value on the client side
>f> *before* the insert to ever find it back safely. So what you could
>f> do is put the code in your trigger that builds the BELEGNR into a
>f> storedproc.
>
>f> change your trigger to select the value from the sp when it's null.
>
>f> then, instead of using AfterPost (GER: da ist das kind schon in den
>f> Brunnen gefallen! sorry don't know this in english :), you can
>f> do something like
>
>Thank You Frank, exactly that way I did it after the hint of Svein.
>Shame that I haven't seen it myself ;-)
>
>f> This way you still have an "atomic place" -> the sp where the
>f> number is assembled, used both by the app and (if necessary) the
>f> trigger.
>
>But I am still not shure if the SP is really Atomic, because it does
>something like:
>
>1) read state
>2) decide about new BELEGNR
>3) update state
>4) return BELEGNR
>
>If two Clients run this SP concurrent step 1 and 3 are within one
>Transaction, but doesn't it depend on my Transaction settings if this
>code is secure? I have Isolation tiCommitted and Autocommit True, but
>should'nt I use a separate Transaction with Isolation tiConsistency?

Dieter,
I think you are needlessly concerned about the atomicity of
generators. *Every* pull from a generator is atomic, by
nature. Generators are completely outside transaction control (the *only*
thing in FB/IB that is so). Once generated, a number cannot be generated
again for anything else.

You would achieve no less atomicity if you simply used GeneratorLinks, or
the Gen_ID() method of either the dataset or the connection object.


regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com