>I have a question...I'll try to strip this down to the bare essentials.
>
>Let's say there's a VFP application that runs against SQL Server.
>
>User 'A' goes into a module where promotion plans are entered. He filters on all promotion plans for a market for the 1st qtr 2002, and pulls back 25 plans. Let's say he does this at 8:00 AM.
>
>User 'B' goes into the same module, and does a filter such that he returns at least one of the 25 plans that user 'A' pulled back. He does this later in the morning.
>
>User 'A makes a change to one of the records around noon, and it is saved back to the SQL Server database. The record he changed is one of the records that User 'B' pulled down earlier...except that User 'B' now has an 'outdated' record. The possibility exists that User 'B' could make a change to the now 'outdated' record, and save it later in the day.
>
>I realize we could look at LASTUPDATE and examine each individual field for changes (synchronization logic), but that seems like it could be very complex.
>
>Our general strategy is to use Pass-through and stored procedures to bring data back to users as VFP cursors, and then Pass-through and triggers to update data everytime a user clicks SAVE. I guess the question is whether there is any way to make cursors returned from SPT 'dynamic' in nature, such that changes made by others are somehow 'refreshed' (and at this point, I think I'm really streching)...
>
>Any thoughts/ideas?
>
>TIA,
>Kevin

Kevin,
One suggestion would be to implement a "user trigger" so that you know when the user actually starts editing the record. This could be as simply as clicking a button with the caption "Edit" or as complex as code in the InteractiveChange event to triiger this change.

In either case, the trigger would fire code via SP or SPT to "lock" the record in question. You could have a flag field on the backend to tell who is editing or it could simply be a bit field saying the record is locked.

The second user would have a read-only copy of the record and yes, it would be outdated. However, when they attempted to edit it, the system would detect the lock already in place and not let them. You wouldn't have data integrity issues.

HTH.