>>The locking strategy my users want is that if they choose to modify a record already being modified to display a message and disallow editting. The approach I took with my first couple of apps, which access the tables directly, was to use:
>>
>>

>>IF RLOCK()
>>    editing code goes here
>>ELSE
>>    message box saying record already being editted by someone else
>>ENDIF
>>

>>
>>The project I'm working on now has tables that will contain a lot of project related data for all ongoing projects so parameratized views, based on project number, are being used. I need a good record locking strategy to do exactly as above except with views. Any ideas? TIA
>
>View is always in exclusive possession of particular user, so RLOCK() will give you nothing. Basically, view-oriented interface is not for pessimistic-locking functionality. You can still go to the underlying table and RLOCK() there, but it looks as redundant for view-based interface.

Thanks for the quick reply Ed. I guess my basic problem is the parameratized views will be faster than filtered tables but I have to have the locking approach as above. My users feel the whole approach of editing a record and then finding out another user edited and saved the same record in the meantime is stupid and ineffecient. I think I'll try the RLOCK() of the underlying table approach. There may be a minor performance penalty but since it will only occur when trying to edit it shouldn't be a big deal. Thanks again.