Hi Ronni,
the standard way of ensuring uniqueness, is to use generators. That
is, change your procedure to

> now there is a loop, for user A : 1 to 100
> - get ticketnumber: ticketnumber = GEN_ID(<generator_name>, 1)
> - //do not use increment, it always cause problems in a multiuser

environment

> - write new record in table ticketpos (ticketnumber 100001)

This does not ensure the ticketnumbers for user A to be consecutive,
you may end up with user A getting ticket numbers 100001 and 100003,
whereas user B may get ticket number 100002, and in case of rollback
you may encounter numbers that are not used at all. However, you will
never experience duplicate keys.

http://www.ibobjects.com/docs/ti_AuditableSeries.ZIP may also give you
some useful information, depending on what you are trying to do.

Hope this helps,
Set

--- In IBObjects@yahoogroups.com, "ronald_greven" <ronald_greven@y...>
wrote:

> Hi,
>
> First of all, sorry about my bad english, I hope you understand,
> which problem I have.
>
> I have a big problem.
>
> I use IB_Objects with a firebird database. Its an multiuser-
> environment.
> There is a table called tickets with only one row.
>
> number ticketnumber
> 1 1000000
>
> in a one-user environment, no problem.
> But :
>
> Input (User A) : A amount of 100
> Input (User B) : A amount of 300
>
> now there is a loop, for user A : 1 to 100
> - get ticketnumber
> - inc ticketnumber with 1
> - write new record in table ticketpos (ticketnumber 100001)
> - write back new ticketnumber in table ticketpos
>
> in table ticketpos the unique index is for the ticketnumber
>
> the same loop for user B : 1 to 300
>
> there are 2 active transactions. Each increase the value

ticketnumber

> with 1 and write it back.
> now a error occurs : attempt to store duplicate value visible to
> active transaction....
>
> how can i let one transaction wait (ex. user A) for the commit of

the

> other active transaction (user B)?
>
> Wow, that was hard to explain. But I hope, you can help me...
>
> Best regards
>
> Ronni