Running into something weird and I'm hoping someone can give me ideas about how to track it down. This is in the same large vertical I've asked about before, where we've recently converted from FPW forms to real VFP forms.

We're seeing a number of users running into error #1502 ("Cannot write to the selected record because it is in use"), mostly with the same table (which is a great-grandchild in a hierarchy of tables). The relevant table has buffermode = 4. All tables are free tables (because for the moment, the FPW version of the application still has to be supported, but the problem is happening both at customers working with both versions and customers using only the VFP version).

When I dig into our error log, I find that in addition to whatever record the user was working on (sometimes an existing record, which shows as locked; sometimes a new buffered record), another record (in a couple of recent cases, two other records) in the same table shows up as changed. To be specific, GetFldState returns 2 for the PK field, though the actual value hasn't changed. (I'm aware that simply replacing with the same value results in marking the field as dirty.) What's really puzzling, given pessimistic buffering, is that the record(s) marked as dirty isn't locked. Shouldn't pessimistic buffering mean that as soon as a field is changed (even to the same value), the record is locked? When I tested manually, that's what happened.

The record pointer is sitting on this dirty record (or the first dirty record, if there's more than one), which makes sense to me because TableUpdate() has failed, so it stopped processing on the record that failed. The TableUpdate() call (which is inside a wrapper routine that, among other things. logs failure and tells the user) is:

IF NOT TABLEUPDATE(m.llAllRows, .T., m.lcAlias)

Pretty sure we're passing .T. for llAllRows everywhere. Definitely the case here.

I've confirmed that this user doesn't have the table open in another work area.

So the mysteries here are:

1) How is the buffer getting dirtied without locking the record?
2) Since error 1502 indicates that someone else has the record in use (though we log explicit locks and we're not finding locks for the relevant records in our log), how was another user able to lock this record? Or alternatively, if someone else had the record locked, how was it able to be changed by this user?

Ideas, anyone?

Tamar