Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

How To Get Last Inserted Record Value In SQL Server Expand / Collapse
Author
Message
Posted Tuesday, April 27, 2010 8:09 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 12:32 PM
Points: 440, Visits: 3,268
TheSQLGuru (4/27/2010)
Tables are UNORDERED sets of data unless they have a CLUSTERED INDEX on them.


Tables are unordered sets even if they do have a clustered index. A clustered index is just one form of internal storage. It doesn't impose any logical ordering any more than a nonclustered index on a heap does.


David
Post #911150
Posted Tuesday, April 27, 2010 9:30 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:18 PM
Points: 36,750, Visits: 31,199
David Portas (4/27/2010)
TheSQLGuru (4/27/2010)
Tables are UNORDERED sets of data unless they have a CLUSTERED INDEX on them.


Tables are unordered sets even if they do have a clustered index. A clustered index is just one form of internal storage. It doesn't impose any logical ordering any more than a nonclustered index on a heap does.


Heh... obviously not a fan of WITH (INDEX(0)) or the "Quirky" Update, huh?


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #911235
Posted Tuesday, April 27, 2010 9:48 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 12:32 PM
Points: 440, Visits: 3,268
Jeff Moden (4/27/2010)
Heh... obviously not a fan of WITH (INDEX(0)) or the "Quirky" Update, huh?


WITH (INDEX(0)) doesn't mean a table is ordered. It just specifies a hint for an execution plan. In fact it doesn't even order the query results AFAIK because the INDEX hint without ORDER BY results in an unordered scan. Rows might be returned in allocation order rather than cluster key order or they might be reordered by a merry-go-round scan.


David
Post #911251
Posted Tuesday, April 27, 2010 11:39 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Sunday, May 11, 2014 8:07 PM
Points: 891, Visits: 235
The order in which records are inserted does not hold any significance unless you specifically track the insert time details.
Also the order in which records are stored does not hold any significance in the table if you do not have clustered index or auto increment or ordered data.



Post #911325
Posted Wednesday, April 28, 2010 2:31 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Friday, July 18, 2014 12:13 PM
Points: 2,837, Visits: 1,138
Just to make sure we completely cover the topic:

An IDENTITY column will help you find the most recently-inserted row, unless IDENTITY_INSERT or DBCC CHECKIDENT (RESEED) are used to insert records out of order.

A TIMESTAMP column will allow you to find the row used in the most recent INSERT or UPDATE.

A DATETIME column with DEFAULT GETDATE() will work for single-row inserts, but if multiple rows are inserted in the same statement they will all have the same value.



Post #912369
Posted Wednesday, April 28, 2010 3:01 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Today @ 12:32 PM
Points: 440, Visits: 3,268
Scott Coleman (4/28/2010)
An IDENTITY column will help you find the most recently-inserted row


Possibly it will if your inserts are serialized. If you have multiple connections with multi-statement transactions then it all depends how you define "most recent". It is quite possible to have identity values interleaved from two near-simultaneous operations for example even though one of them could commit before the other. I think it is safest to assume IDENTITY order is non-deterministic and will not necessarily match insertion order (whatever "insertion order" means) except in the special case of a single connection inserting one row at a time.


David
Post #912385
Posted Wednesday, April 28, 2010 4:08 PM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 3:19 AM
Points: 4,320, Visits: 6,113
>>A DATETIME column with DEFAULT GETDATE() will work for single-row inserts, but if multiple rows are inserted in the same statement they will all have the same value.

Here is another incorrect statement too (actually more than one failure).

1) That DEFAULT only helps if the INSERT doesn't explicitly state a value for the DATETIME column, which is certainly possible.

2) You are at the mercy of the 3.33ms precision of the DATETIME datatype. A busy system could easily have more than one concurrent insert within that interval - both will receive the same datetime value.


Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Post #912412
Posted Thursday, April 29, 2010 7:31 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: 2 days ago @ 9:00 AM
Points: 1,595, Visits: 4,585
The technical puzzle proposed in this discussion is interesting, but it has obviously run it's course. I'm interested about why you would need to know the "last" value inserted into a table that contains only a single column called [Name]. For example, are you trying to page through the list of names in an application, or perhaps you're incrementally loading data and need to know where you left off? If you describe more detail about your intended goal, then perhaps someone can offer a better solution to the actual problem.
Post #912828
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse