IDENT_CURRENT and empty table

[helmut woess]

Hi,

can somebody explain me, why the IDENT_CURRENT from an empty table is 1?
After insert of the first record it is still 1 (assuming that start value
is 1) which is okay. But if i check the IDENT_CURRENT from a newly created
table the result should be NULL, or not?

bye,
Helmut

[--CELKO--]

>> But if i check the IDENT_CURRENT from a newly created table the result should be NULL, or not? <<

What would a NULL value mean? Why not zero? Remember IDENTITY is
proprietary and non-relational, so it can do anything it wants.

Think about how it would work if you had a 1950's sequential tape file
system. The counter starts at one and is incremented after the
insertion instead of before. It is the position of the read/write head
of the maganeitc tape drive.

[helmut woess]

Am 18 Sep 2005 07:57:39 -0700 schrieb --CELKO--:

But if i check the IDENT_CURRENT from a newly created table the result should be NULL, or not? <<

What would a NULL value mean? Why not zero? Remember IDENTITY is
proprietary and non-relational, so it can do anything it wants.

Think about how it would work if you had a 1950's sequential tape file
system. The counter starts at one and is incremented after the
insertion instead of before. It is the position of the read/write head
of the maganeitc tape drive.

We have NULL to mark something as unknown. Why not using it?
In the manual IDENT_CURRENT is described as "gives back the last generated
ident value". So from my logical point of view it cannot give back a value
if it has not generated a value before. And because zero can be a valid
starting value it can't give back zero.
Maybe it would be better we have a IDENT_NEXT which shows the next value
which will be used, instead of IDENT_CURRENT. This could avoid such
misconception.

bye,
Helmut

[Dan Guzman]

http://support.microsoft.com/default...b;en-us;835188

--
Hope this helps.

Dan Guzman
SQL Server MVP

"helmut woess" <[e-mail]> wrote in message
news:1q*****************************@40tude.net...

Hi,

can somebody explain me, why the IDENT_CURRENT from an empty table is 1?
After insert of the first record it is still 1 (assuming that start value
is 1) which is okay. But if i check the IDENT_CURRENT from a newly created
table the result should be NULL, or not?

bye,
Helmut

[helmut woess]

Am Sun, 18 Sep 2005 17:58:46 GMT schrieb Dan Guzman:

http://support.microsoft.com/default...b;en-us;835188

Hmmm, i am not sure what to do with this information. If it is a bug why
was it not fixed in one of the next service packs?
And there is no definition what the result will be after fixing the bug.
And i did not find any information if this bug is fixed in SQL2005.

In the meantime i wrote an UDF to check if the table is empty and then give
me the right result. So it doesn't matter if Microsoft fixes the bug or
not.

but thanks for your information,
Helmut

[Erland Sommarskog]

helmut woess ([e-mail]) writes:

Am Sun, 18 Sep 2005 17:58:46 GMT schrieb Dan Guzman:

http://support.microsoft.com/default...b;en-us;835188

Hmmm, i am not sure what to do with this information. If it is a bug why
was it not fixed in one of the next service packs?
And there is no definition what the result will be after fixing the bug.
And i did not find any information if this bug is fixed in SQL2005.

The behaviour is the same in SQL 2005.

But the funny thing is that Books Online for SQL 2005 explicitly says that
you should get NULL back in this case...
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Dan Guzman]

As Erland mentioned, the bug hasn't yet been addressed. Your UDF
work-around is probably the best apporach.

May I ask why you need to use IDENT_CURRENT? The function has a global
scope so it needs to be used with caution in a multi-user environment.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"helmut woess" <[e-mail]> wrote in message
news:1v*****************************@40tude.net...

Am Sun, 18 Sep 2005 17:58:46 GMT schrieb Dan Guzman:

http://support.microsoft.com/default...b;en-us;835188

Hmmm, i am not sure what to do with this information. If it is a bug why
was it not fixed in one of the next service packs?
And there is no definition what the result will be after fixing the bug.
And i did not find any information if this bug is fixed in SQL2005.

In the meantime i wrote an UDF to check if the table is empty and then
give
me the right result. So it doesn't matter if Microsoft fixes the bug or
not.

but thanks for your information,
Helmut

[Erland Sommarskog]

Erland Sommarskog (es****@sommarskog.se) writes:

helmut woess ([e-mail]) writes:

Am Sun, 18 Sep 2005 17:58:46 GMT schrieb Dan Guzman:

http://support.microsoft.com/default...b;en-us;835188

Hmmm, i am not sure what to do with this information. If it is a bug why
was it not fixed in one of the next service packs?
And there is no definition what the result will be after fixing the bug.
And i did not find any information if this bug is fixed in SQL2005.

The behaviour is the same in SQL 2005.

But the funny thing is that Books Online for SQL 2005 explicitly says that
you should get NULL back in this case...

Got an update: Books Online for 2005 is wrong and will be updated.
The current behaviour will not change, because it could cause compatibility
issues.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[helmut woess]

Am Tue, 20 Sep 2005 12:39:32 GMT schrieb Dan Guzman:

As Erland mentioned, the bug hasn't yet been addressed. Your UDF
work-around is probably the best apporach.

May I ask why you need to use IDENT_CURRENT? The function has a global
scope so it needs to be used with caution in a multi-user environment.

Hello,

sorry for delay, but i was tied up with vacation :-))
The reason why i read this value in my application is as following:
All records own an identity field (which is always the primary key), which
is used to log all data activities in a log table which has an identity
field too. When i add a new record, then this record gets its identity
value and the trigger afterwards logs this insert into the log table which
creates a new record in the log table. But this insert in the log table
changes @@IDENTITY, and the ado component in my application gets this value
as new identity value, not the value from the original insert - i needed
some days to find out this behaviour. And my grid for displaying the data
jumps to the wrong record ...
So i read this value before i do the post and after posting the data i do a
refresh of the data and a repositioning in the grid to the identity value i
got with reading ident_current before.
So if something goes wrong the worst case could be that the grid shows a
wrong record. But because in my application every record has a lot of data
to set and everything has to be done by hand and there are max. 3 users at
the same time adding records into the same table i can live with this risk.

bye,
Helmut

[David Portas]

Assuming you are using SQL Server 2000 then use SCOPE_IDENTITY() rather
than @@IDENTITY. SCOPE_IDENTITY won't be affected by an insert in the
trigger.

--
David Portas
SQL Server MVP
--

[helmut woess]

Am 27 Sep 2005 02:04:29 -0700 schrieb David Portas:

Assuming you are using SQL Server 2000 then use SCOPE_IDENTITY() rather
than @@IDENTITY. SCOPE_IDENTITY won't be affected by an insert in the
trigger.

I think there was a litte misunderstanding, i don't use @@identity, i use
ident_current(). The problem is not in the trigger, it is in the ADO
component from Delphi. It looks like the component is reading @@identity
instead of scope_identity(), so it gets the wrong value.

bye,
Helmut