>Larry,
>
>Thanks for responding [I'm slow getting back on responses these days].
>
>My follow-up question (this was the issue of locking records in a VFP front-end and SQL Server at the back end when I'm using SPT]...our DBA doesn't believe in the concept of an external table that contains integer keys of records that are locked, nor in the idea of an extra field in each master header table.
>
>He believes that 'lock hints' in SQL Server are sufficient. I've read the documentation on 'lock hints', and admittedly I'm a bit confused. Based on what I've read, I'm unable to determine if lock hints will give me what I want - to be able to 'lock' a record back in SQL when I want to edit it, such that others would not be able to edit it [they'd get a validation message that I could trap, indicating that another has the record].
>
>So would 'lock hints' do the trick, or aren't they sufficient?
>
>Thanks,

Kevin,
Using a combination of ROWLOCK and HOLDLOCK will give the the VFP RLOCK equivalent until you release the transaction. They're usable but then you run into the same issues I noted in another post to you about setting up timeouts or modifying all your Select statements to include the READPAST hint as well. If you don't then when you attempt to use a row that has been locked, SQL Server, by default, will pause until the lock has been released.

I guess it depends on which best suits you (and your DBAs).