guaranteed per connection so connection
pooling can stuff it up (under heavy loads)
Neven
- Original Message -
From: Paul Ritchie [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Thursday, 11 January 2001 18:04
Subject: RE: RE: [DUG]: [DUG-DB]: Unique IDs
-
From: Neven MacEwan [mailto:[EMAIL PROTECTED]]
Sent: Friday, 12 January 2001 08:49
To: Multiple recipients of list delphi
Subject: Re: RE: [DUG]: [DUG-DB]: Unique IDs
Paul
Sorry I wasn't quite clear I meant @@Identity
ie
If the statement fires one or more triggers that perform inserts
Paul
But your second point does concern me. Basically you're saying that under
stress and with multiple connections, an identity column may return the
same
value twice. Can you point me to a link that confirms that? I understood
they were pretty much bullet proof.
Unfortunately not - I
Can you point me to a link that confirms that?
I found a newsgroup thread on Deja on this issue:
++
This makes me think the @@identity variable is extremely unreliable
when used in the middle tier.
If you return/use the value from the same batch, you don't have a problem
with
Stephen
think about it last night why do you
1/ Code the 'generator' using a global table with an identity column
ie
create proc GetID as
begin
declare @NewID int
insert into GenTable (InUse) values ('Y')
set @NewID = @@identitiy
return @NewID
end
then call this outside your
ist delphi
Subject: Re: [DUG]: [DUG-DB]: Unique IDs
Stephen
think about it last night why do you
1/ Code the 'generator' using a global table with an identity column
ie
create proc GetID as
begin
declare @NewID int
insert into GenTable (InUse) values ('Y')
set @NewID = @@identitiy
ret
updating all the other records that used the
keys after it.
Nic.
- Original Message -
From: "Neven MacEwan" [EMAIL PROTECTED]
To: "Multiple recipients of list delphi" [EMAIL PROTECTED]
Sent: Friday, January 12, 2001 9:53 AM
Subject: Re: [DUG]: [DUG-DB]: Unique IDs
...
Neven
- Original Message -
From: Stephen Bertram [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Friday, 12 January 2001 11:27
Subject: RE: [DUG]: [DUG-DB]: Unique IDs
Neven
You are right in the "normal" cases. What I'm thinking of (don't read
th
delphi" [EMAIL PROTECTED]
Sent: Friday, January 12, 2001 9:34 AM
Subject: Re: RE: [DUG]: [DUG-DB]: Unique IDs
Paul
But your second point does concern me. Basically you're saying that
under
stress and with multiple connections, an identity column may return the
same
value twice. Can yo
Nic
Yes, So you had the cascaded insert problem, I was more worried about
connection sharing and
not using batches
Neven
---
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website:
for it.
Can't find the reference now tho.
N
- Original Message -
From: "Neven MacEwan" [EMAIL PROTECTED]
To: "Multiple recipients of list delphi" [EMAIL PROTECTED]
Sent: Friday, January 12, 2001 10:52 AM
Subject: Re: RE: [DUG]: [DUG-DB]: Unique IDs
Nic
Yes, So you had
use the NewID() function
IE:
Create table fred (Globally_Unique_Id uniqueidentifier default NewID() not
null)
will give you a GUID that is unique across everything.
The NewID() function will return a GUID and it will never return the smae
one again.
I need a bulletproof routine to create
The NewID() function will return a GUID and it will never return the smae
one again.
... or not for a couple of quadrillion years anyway!
:-)
David Brennan.
DB Solutions Ltd.
---
New Zealand Delphi Users group -
[Reply]
Your requirement needs to have a process that is not available in most databases. You
need some logic to not only give you a
sequential number, but to also remember "roll backed" ID's and issue those before
generating new ID's.
This usually requires the creation of a pool of available
Stephen
Code your own 'generator' as a stored proc using a UniqueIdentifier (GUID)
datatype
and the NEWID() function
Neven
- Original Message -
From: Stephen Bertram [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Thursday, 11 January 2001 15:31
I need a bulletproof routine to create unique integer IDs for
inserting rows into multiple tables in a MSSQL 7 database.
If you are happy to use 2 integers to uniquely identify such a row, then you
could use the ID of the table in sysobjects as well as an identity column in
the table itself.
m prepared to type in huge banks of guff in SQL when tracing
rows. I'll think about it.
Stephen
-Original Message-
From: Gary T. Benner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 11 January 2001 3:48 p.m.
To: Multiple recipients of list delphi
Subject: RE: [DUG]: [DUG-DB]: Unique IDs
[Re
The suggestion that Gary has put forward is exactly what I was thinking
of,
but I still don't see how to "remember" rolled back ID's.
do you really need to? does 1 2 3 6 7 8 9 10 14 16 17 make a difference, as
long as they are all in order whats it for?
N
:[EMAIL PROTECTED]]
Sent: Thursday, 11 January 2001 4:52 p.m.
To: Multiple recipients of list delphi
Subject: Re: [DUG]: [DUG-DB]: Unique IDs
The suggestion that Gary has put forward is exactly what I was thinking
of,
but I still don't see how to "remember" rolled back ID's.
do you r
but I would be more tempted to add a seperate timestamp or
datetime column containing the time the row was inserted.
Whoops. Upon reflection I don't think a timestamp column would add any more
information as to the order the rows were added than the original identity
column already provides.
Bertram [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Thursday, 11 January 2001 16:55
Subject: RE: [DUG]: [DUG-DB]: Unique IDs
The discussion so far has brought up 2 issues for me -
Why not use GUIDs
Size
Difficulty in manual SQL manipulation
Lack of a directly
Re
The problem is :
Process 1 generates 11
Process 2 generates 12
Process 3 generates 13
Process 1 issues a rollback - ID 11 is now unused
Process 4 generates 11 - based on rolledback seed value.
Process 5 generates 12 !! Duplicate
Process 6 generates 13 !! Duplicate
more like
Process 1 generates 11
Process 2 generates 12
Process 3 generates 13
Process 1 issues a rollback - ID 11 is now unused
Process 4 generates 11 - based on rolledback seed value.
Process 5 generates 12 !! Duplicate
Process 6 generates 13 !! Duplicate
Or am I missing something here? I can't
recipients of list delphi
Subject: Re: [DUG]: [DUG-DB]: Unique IDs
The suggestion that Gary has put forward is exactly what I was thinking
of,
but I still don't see how to "remember" rolled back ID's.
do you really need to? does 1 2 3 6 7 8 9 10 14 16 17 make a difference, as
long as th
(Interbase is so easy in this sense because generators are
produced outside any transactions).
So are SQL Server identity columns, and I've got to say they're even easier.
ducks for cover
Paul Ritchie.
---
New
UG tut tut :-)
Neven
- Original Message -
From: Paul Ritchie [EMAIL PROTECTED]
To: Multiple recipients of list delphi [EMAIL PROTECTED]
Sent: Thursday, 11 January 2001 17:37
Subject: RE: RE: [DUG]: [DUG-DB]: Unique IDs
(Interbase is so easy in this sense because generators are
produc
Neven,
Well you learn something new every day eh?
a/ They are only unique to a connection and
I didn't think so. Aren't they generated from within the database? I use
them in stored procedures and I don't see how they could be only unique to a
connection. Can you point me to documentation
27 matches
Mail list logo
