Well, that's always my first thought when I can't replicate a problem. However, in this case, knowing that the first thing I wanted to do to the file was zap it, I just sent them a blank copy of the file to overwrite the one that wasn't opening. Then I removed the need (for the short term) to open the file exclusively and zap it. However, that file wouldn't open, either (at least not in the real program - in the test app it opens fine!?).

I didn't see anything in that article that indicated the issue could affect a separate table. It seemed to be limited to a single table and locking a record in a large table would only potentially cause problems in that same table. But, in any event, the largest file is about 11 MB.

The system factors are theirs. It definitely a Win2K server, but I'm not sure about the desktop OS. I'd like to know about the compatibility issue you mention, however I don't get as far as locking. I can't get the darned file open! :~)

Thanks for your efforts.

Russell

>Do you think it could be related to actual data on the client's system. A situation that you cannot replicate because their data has certain conditions that your local data doesn't.
>Things like a cursor with the same name open at the client's but never on yours? Possibly they have other large tables that are open and the article I pointed to is causing the troublesome file to appear locked.
>It sure sounds to be related to the application itself, and given that it's fine on your system only the data (and the conditions that may arise because of it) remains to suspect.
>
>By the way, are the system factors shown at the top pertinent to the client's system or to yours? If, for insytance, they are running on non-XP file server but using XP on workstations there is a known bug with locking INCOMPATABILITY between the two.
>
>again, good luck
>