From the KB link (click the plus sign next to APPLIES TO):

APPLIES TO

Microsoft SQL Server 2005 Developer Edition
Microsoft SQL Server 2008 Developer
Microsoft SQL Server 2008 Enterprise
Microsoft SQL Server 2008 R2 Developer
Microsoft SQL Server 2008 R2 Enterprise
Microsoft SQL Server 2005 Enterprise Edition
Microsoft SQL Server 2005 Evaluation Edition
Microsoft SQL Server 2005 Standard Edition
Microsoft SQL Server 2008 Standard
Microsoft SQL Server 2008 Workgroup
Microsoft SQL Server 2008 Web
Microsoft SQL Server 2008 Standard Edition for Small Business
Microsoft SQL Server 2008 R2 Standard
Microsoft SQL Server 2008 R2 Web
Microsoft SQL Server 2005 Workgroup Edition
Microsoft SQL Server 2005 Enterprise X64 Edition


>Hi Tracy,
>
>At the top it says: View the products this KB applies for, but I never can see the products. What products you're seeing?
>
>>Which version of SQLServer?
>>Bug:
>>http://support.microsoft.com/default.aspx?scid=kb;en-US;2019779
>>http://connect.microsoft.com/SQLServer/feedback/details/328811/scope-identity-sometimes-returns-incorrect-value
>>Neat explanation:
>>http://www.codeproject.com/KB/database/SQL_IDENTITY.aspx
>>
>>>You are correct that it is an issue with remote views. But the app I am refactoring is a VFE app with remote views pretty much baked into the framework. In our own development we always used guid() keys, but the schema here uses identity keys. The only issue comes of course with adding new records.
>>>
>>>In any case, SCOPE_IDENTITY indeed does not seem to be an option with remote views. I may be missing something but I don't see where @@identity would be any more or even as reliable.
>>>
>>>In a low concurrency app, should I be concerned about IDENT_CURRENT? Seems it would be at least as reliable as SCOPE_IDENTITY. If I am hitting the backend with tableupdate() ( i.e. INSERT ) and then SELECT IDENT_CURRENT('tablename') it would seem the only problem would be if someone else inserted a row in whatever nanosecond existed between my two requests and in this scenario I think that is a risk I'm willing to take. And I supposed if I were really paranoid about it I could get the value before the insert and after the insert and compare the difference with the seed increment value.
>>>
>>>( since some of the refactoring on this project rescue includes that currently the data is fetched with a remote view, copied into local VFP cursors - don't ask - then copied, field by field into control values - yes, that's right, no data binding !!!! - then copied back again to those cursors then used to construct an SPT statement to do the save - but the good news is SCOPE_IDENTITY works in this scneario <g> - then ... oh god you don't even want to know ... I'll just be glad to get the plumbing working in a fashion where my greatest fear is the concurrency scenario above <bg> )
>>>
>>>>How do you use scope_identity with remote views? That is the problem I've been working on and ident_current seems to be the solution there as there is a VFP transaction wrapped around this and I think there is a lock. In any case while I am in the VFP transaction SSMS cannot get SCOPE_IDENTITY or query the table or much of anything else. I am sending tableupdate and then immediately doing SPT to get IDENT_CURRENT('tablename')
>>>>
>>>>If try to get SCOPE_IDENTITY in the same scenario it is null.
>>>>
>>>>I just noticed a minute ago that you posted a similar question to me from another thread, and I overlooked it, sorry.
>>>>
>>>>You're probably not going to like the answer (and I know that my friend from New Zealand won't like the answer much either), but I don't use remote views. I don't mean it in an overly negative way, I just don't care for certain wrappers in OLTP applications.
>>>>
>>>>I am going to take a guess that in a remote view, after the update commits, the scope is lost but not the session. (And maybe you already realized that). That would explain why some functions work but scope_identity doesn't. It sounds like this is an inherent issue with RVs. (I'll be happy to be proven wrong)
>>>>
>>>>Don't know if this will help, but Dmitry Litvak posted something about a year ago, related to code published from the VFP team, for using CursorAdapters to get around this issue. It's Message #1475311.