>I'm working (as I've mentioned) on moving a large vertical from FPW screens (running in VFP) to VFP forms. It was originally based on the Stonefield Appmaker framework and we've created our own VFP framework based on making pretty much the minimal changes from the original Stonefield code. It's mostly converted and mostly working well, but we're running into a handful of issues that may all be related to locking. So I'm curious to hear what settings (especially for REPROCESS) folks are using.
>
>In this case, we're using a buffering setting of 4-pessimistic table locking. The goal is that only person can be editing a given record at any time. In fact, we're also explicitly locking records when entering edit mode, including not just the record on the form, but other related records.
>
>The most frustrating of the errors and the one that finally prompted this post is that every now and then, we're unable to lock a record in the table that we use for tracking primary keys. (The app has to remain compatible with FPW2.6, so auto-generated PKs aren't an option.) Weirdly, it happens more with the record for one particular table (which is not the largest table and doesn't have records added at a pace that might raise questions) than others.
>
>So, how do you have your locking set up and what challenges have you run into?
>

Hi Tamar
from my Environment class
[snip]
SET REPROCESS TO -1 &&Standard 0
[/snip]

All data processing except full exclusive transfers through Cursoradapter, former through Views, all optimistic table buffering, DBKeyAndModified, control by a time-stamp. All runs on single machine (terminal server), so time is synced.

Most trouble with the buffering is how to figure out you WILL change a row in a grid, found no solution then jumping back from new selected record, so the use of the table buffering.
The tableupdate is called by explicit methods of the CA.
Set up in the 90's, runs stable since..

I have stuff where a longer import runs non-exclusive.
I also have very wide data that I can handle by 1:1 relationships only.
This I lock via a synthetic locking by an integer field that controls what in specific is locked (I must lock all 1:1 records but some special write operations might be ok some times, and a write might even lock related records in a child table )
For the long duration operations a second instance writing will raise a special form to notify the user (by the information of the integer locking even with the type of process locking) . The user might interrupt the write from this form by mouse/kbd

Biggest problem is to control the update of several tables, but this is not related to SET REPRO.

HTH
Lutz