Hello:

The generator is not a good solution because I don´t want "holes" in the
code sequence, which may occur, for example, if John cancells.

But I found a solution. In every table I already have a field named A_RECNO
wich is a unique number and is obtained using a generator. When a user is
adding a record, while it is not commited, I add 10000000 to the value of
A_RECNO and just before he commits, I substract 10000000 to this field. So,
of Peter makes a refresh (before commiting), in its SELECT, in the WHERE
clause there is (A_RECNO >= 10000000) and in this way he will only see his
records and not the ones of John (if John has already commited, the A_RECNO
fields of his records will not be >= 10000000).

Perhaps it is not an "elegant" solution, but it works perfect!

Thank you very much.

Gustavo

----- Original Message -----
From: "Adam" <s3057043@...>
To: <firebird-support@yahoogroups.com>
Sent: Friday, July 27, 2007 9:25 PM
Subject: [firebird-support] Re: Two users adding a record with the same code


>>
>> Suppose I have a Table of ENTERPRISES with a field CODE (numeric),
> NAME, ADDRESS, etc. Then I have a table EMPLOYEES with a field
> ENTERPRCODE, NAME, AGE, ADDRESS, etc. Suppose there are already 100
> entreprises in the table ENTERPRISES.
>
> Hello Gustavo,
>
> If your CODE is the primary key of the table, then it should be of no
> interest to John or Peter. If code is some organisation level
> identifier, then surely they already have some mechanism to serialise
> the allocation so this can not happen in their current manual process?
>
> Assuming they don't, and you want Firebird to prevent this:
>
> Either:
>
> * Pre-allocate the CODE; or
> * Design your program so it has some form of CODE conflict resolution.
>
> Pre-Allocation
> --------------
>
> The easiest way is to call a Generator, and that is your code you can
> use in your client application. If someone hits cancel or has their
> computer crash or whatever, you will get 'holes' in the code sequence,
> which may impact you for say legal rules about invoice numbering. In
> this case, John would get 100, Peter 101, but if one cancelled, the
> number would never been seen again.
>
> Another way is to create a holding table for CODEs. When your
> application wants a code, it must insert it into that holding table
> (which has a unique constraint). When finished, you can remove the
> code from the table. In this case, Peter would no from the start that
> 100 was not an option.
>
> Conflict Resolution
> -------------------
>
> The other way to do it is to design your application so that when
> Firebird reports the conflict, you present the screen to the Peter
> that 100 is already in use, and allow him to choose a different code.
>
> Adam
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://www.firebirdsql.org and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
> __________ Información de NOD32, revisión 2426 (20070727) __________
>
> Este mensaje ha sido analizado con NOD32 antivirus system
> http://www.nod32.com
>
>