>....
>>>>I thought that @@IDENTITY will get the last identity on the "current session". Therefore, I thought that it should not get the value of new identity created by another user (that is, another session). Am I wrong?
>
>I dimly remember @@IDENTITY, @@SCOPE_IDENTITY and a side effect of the connection method. As you are probably using vfp9. are you using ODBC ? It is boredering on monkeypatching, but if you connect via OLE_DB, try @@SCOPE_IDENTITY if you can get reproducible errors with the current setup at this client...
>

Changing the app from connecting via ODBC to OLE_DB is a change that I cannot afford to do right now. Some things may start breaking up and I have enough on my plate right now to deal with.

>>>>
>>>>UPDATE. This customer who is giving me the problem (or the other way around), I think, is using Terminal Server or some similar technology. So I am thinking that - maybe - all users, as far as SQL Server is concerned, are using the same session. Another thing to explore.
>
>Interesting angle. Big DUNNO here... If you have user+timestamp fields for each or at least last action per table already in your DB, you could try to add machine identifier to the user field, perhaps in an switched-around sys(0) format: user # machine. If you really have to code around the issue yourself, such enhanced log fields might open an attack angle after helping to identify the problem. If you want to guard against app being opened twice on same machine, adding process ID could help: remember my line of switching over to client-side PK generation of GUID if DBA settings kill server side geneneration/replication ;-))
>

I already have a code in the application that prevents a user from opening the app twice. I am listening to all your suggestions. But I don't want to change anything in the application (except maybe putting some "test" code to "log" certain conditions) until I know what exactly is causing the problem. I am pretty sure that what you suggested before, that the first user "grabs" the PK of the insert done by the second user, is what happens (sometimes). And I need to figure out Why. Once I know it, I may change the code and approach of how PK is generated or other aspects of the app.

>>>
>>>The most reliable way is to use OUTPUT clause of the INSERT command. I don't remember if we already have VFP samples here in the forum of how to do that, I'd try that.
>
>sounds like a good idea to poke around first...

Until I can "see" that OUTPUT will help, I won't change code that works for 99.99% of the customers.

Thank you.