John,

That's strange. I've found it to be reliable. The key is that it's the last identity value for the connection you use for the SELECT @@IDENTITY. This means that if you use a view you need to use CURSORGETPROP() to get the connection handle the view is using and use that for your SELECT @@IDENTITY. If you have views sharing a connection and you always use that handle you can run into a problem if you've forgotten to set one view to share the connection.

>I've had situations where running SELECT @@IDENTITY came back with a null or zero or some other unexpected value. After going nuts on this for a while, I started adding a surrogate key to tables with an identity datatype as the primary key. This surrogate key I populate from the presentation or data services tier then send the INSERT. I can then refresh and SELECT on the surrogate key and then grad the new identity field value. Yes, I know it's back-asswards but it's the only way I've found to work with those damn identity columns in a foolproof manner.