>>I've got another weird one, but if I can solve it, it may actually be the answer to a bunch of issues in this application.
>>
>>A table is open shared. At a certain point in this application, with no records in this table locked, and the table itself not locked (IsFLocked() returns .F.), other users are getting frozen on attempts to INSERT INTO or APPEND BLANK in this table.
>>
>>Details:
>>
>>- I can replicate the problem testing with two instances of VFP on a single machine with local data. So it's not network issues.
>>
>>- I've doctored things to do a whole bunch of logging (in the instance that's causing the problem) that includes DISPLAY STATUS. The relevant table is open in only one work area and shows "Lock(s): none" (with angle brackets around "none," but those are hard to post).
>>
>>- The "certain point" involves a message being displayed to the user. Once that message is dismissed, other users are able to add records again. The code that displays the message adds one record to this table, but otherwise, doesn't touch it, and that record isn't added until after the message is dismissed.
>>
>>- In my testing, I've simplified to running one instance to the point where this happens, and then in the other instance, opening the table, and issuing APPEND BLANK from the Command Window. I get "Record not available" in the status bar and it just sits until I dismiss the message in the running application.
>>
>>- The table in question is not involved in the main action of the application at this point. It's an activity log. The only interesting/unusual thing about it is that we reuse old records in the log, so that it's not just growing forever.
>>
>>The symptoms I'm seeing suggest that the table header is getting locked somehow, but I can't find any evidence that's happening, including that my logs don't show the header as locked. (I tested and DISP STAT shows you a lock on record 0 when the header is locked.)
>>
>>Thoughts?
>>
>>Tamar
>
>Is the table part of a DBC? If so :
>try validate database recover.
>check for anything in triggers and default values

Thanks. It's a free table. (The application still has to run in FPW, as well.)


>I would try all this:
>delete and recreate all the indexes
>pack the table (if your app won't break as a result)
>if all else fails what happens if you do flock(), append record, then unlock it as soon as new record is added?
>Almost seems like the pointer is getting lost?? very odd problem.

Indexes are deleted and recreated daily. The problem is happening at multiple customer sites, so unlikely to be anything related to corruption.

We've found a workaround, though we still want to find the underlying problem. In the session that has to display the message, we're closing the table just before showing the message and reopening it after the message is dismissed. This is allowing the other session to add records.

That said, there's still something weird going on. I omitted another complication in the original message because it didn't seem relevant here, but now I'm not so sure. The application is designed so that this table (and a couple of others) reuse older records. (Since this is an activity log, we don't need to keep the data forever. The customer chooses whether to reuse records, and if so, how long to keep each record.) Even with the new code that closes the table in one session, in the other session, I'm able to find a record old enough to reuse, but unable to lock it. That makes no sense since in my test scenario, there are only two sessions and the table is open only once in one of them. The attempt to add a new record (which is now working) doesn't happen until we fail to find a record old enough to reuse or fail to lock the record we find.

Tamar