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 Tremel