Hi!

No way to eliminate that extra trip, unless you will make your own SP at the server that will do the record inserting. As I said, when 2 users try to insert record at the same time, the ID should be unique. When you generate the ID at the client side, it is not possible, because the other user does the same,s o it will have the same ID value. Onlye SQL Server can give you the proper answer to the question 'What is the last ID number?'. You can generate GUID at the client side using the API functions (there is a sample in the FAQ articles at the www.tek-tips.com). This is not reliable too, because when GUID generated at the same time on different computers, it might be the same (it is time-depended), I have seen such situations. SQL Server NewID function is more reliable, so better call it.

Well, approach with SP can work - send the INSERT statement to the SP as a parameter, than receive from SP the record set that contains the ID of the new record. However, you require to prepare that INSERT statement. In usual case VFP does this for you when you use the view or updatabale SQL Pass-Through cursor. It is also could be a problem when passing large data durng record insert. A lot of issues to do not mess with this approach.

Why you concerned so much with an extra round trip to the SQl Server? SQl Server (and similar servers) are designed specially to handle a huge amount of very little queries to it. So one additional command/response to SQL Serevr will be quick enough to be acceptable. The query like 'SELECT @@IDENTITY' lasts moments fo second, so I guess there is no real reason to worry about.

HTH.

>Hi, Vlad.
>
>Thanks a lot for your explanation. Are you a MVP already? If you don't, you'll be very soon. :-)
>
>Well, I'd like to eliminate this extra trip do the server to generate this newID, but I still didn't figured out how.
>
>I'll keep studying, and if I discover something, I'll tell you, and everybody who is sending me their comments.
>
>Thanks!