-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Actually in this case you don't have a hole.
Yes you created the next policy (in this case, may be any similar situation).
But the customer already signed the contract. This means even if he opts out
of it, a record has to be kept. In some areas this
It seems to me there is a confusion about identifiers. There is the primary
key of the table which should be a sequence and may have holes. Seperate
from that is the CustomerFriendlyID which is an ID you can assign and
reassign at your leasure. For a bank, the statement numbers all start from one
f
How can you avoid holes?
Unless you void policies that people cancel halfway through the process
? How is that different than rollback?
Lets say that the customer goes through the motions and after signing
the papers, and then during the cooling off period (mandatory in Canada)
decides he really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Obviously depends on the carrier. Lloyds for example doesn't allow numbering
gaps. But as said: doing it in a fully isolated stored proc usually works.
The stp I use also assembles the alpha part, so I end up with something like
AA-0001234 in a fixe
> But, how can I explain to the user, who use the
> sequence numbers, that he will have to handle with
> those holes?
If it's just hte user, you might try to make sure that there are ALWAYS
holes, so he doesn't get confused.
Jon
>
> Ok! I will try to handle the holes! (fight against the
> users
Perhaps the primary key should be a sequence/serial, but also have a
secondary key which is assigned after commit.
You could have a process that continually ran something like:
select max(skey) from the_table;
select pkey from the_table where skey is null;
Then loop through the answers and assig
On Mon, 24 Nov 2003 12:48:26 -0300 (ART)
MaRcElO PeReIrA <[EMAIL PROTECTED]> wrote:
> The biggest problem it that I *can't* have holes in
> that column, so it was because I used id (serial) and
> forn_id (integer).
>
Well, if you cannot use a sequence you will have no choice but to use
locking.
Hi Dave, Marc and all others,
I know it is really weird!
But, how can I explain to the user, who use the
sequence numbers, that he will have to handle with
those holes?
Ok! I will try to handle the holes! (fight against the
users)
Thanks!
Marcelo
--- Dave Cramer <[EMAIL PROTECTED]> escreveu
Marcelo,
You are asking for the impossible.
In order for sequences to work reliably they have to exist outside of a
transaction, and be atomic. If two transactions asked for a sequence
simultaneously, what number would you give them? If the first one gets
1, and the second gets 2 how do you roll
On Mon, 24 Nov 2003 10:20:07 -0300 (ART)
MaRcElO PeReIrA <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> I have a simple table:
>
> teste=# \d forn
>Table "public.forn"
> Column | Type | Modifiers
> -+-+-
Marceio
The sequence logic takes care of it. try it yourself
open two connections with psql
on one do a
begin;
insert into table
select curval('forn_id_seq');
on the other
do a
begin
insert into table
select curval('forn_id_seq');
You will see that they both increment the sequence numbe
Dave,
I actually use just the sequence, as you wrote!
The biggest problem it that I *can't* have holes in
that column, so it was because I used id (serial) and
forn_id (integer).
All other tables use only the sequence by itself, but
this one, especially, CAN'T have holes! It is the
problem!!! ;-
I think that defining forn_id as "serial" is what you are looking for.
This will handle the assignment of unique numbers to the id for you (it creates
a sequence table).
The locking stategy is fraught with danger... and unnecessary.
Marc A. Leith
redboxdata inc.
E-mail:[EMAIL PROTECTED]
Quo
Hi guys,
I have a simple table:
teste=# \d forn
Table "public.forn"
Column | Type | Modifiers
-+-+--
id | integer | not null default
nextval('public.forn_id_seq'::text)
14 matches
Mail list logo
