>>>>I'm trying to correct a problem with some incorrect entries in a table, but when I enter the field and try to change it, the status bar says the 'control is read only'. Trying to use the table exclusively gives a 'File access denied' message. The table is used on a network, but for my most recent test, I shut down all workstations and ran VFP6 on the server containing the database, with the same result.
>>>>
>>>>I had previously copied the table, index and .fpt files to my machine, and I can edit it here with no problem.
>>>>
>>>>Anyone have any idea what the problem could be?
>>>>
>>>>Thanks,
>>>Hi Neil,
>>>
>>>This wouldn't happen to be a Novell server, would it? My experience with that particular OS has not been a positive one. Among other problems, one such as this has gotten me a number of times. If the table is large, Novell servers seem to have a particular problem with properly releasing file handles. Of course, this is just my take on this. It could be something else. I'd try, however, shutting down the other workstations, and re-booting before trying to get a table opened exclusively.
>>
>>In my case, with some versions at least, it was worse than that. I worked on a project that produced an OLE Automation server for shipment rating using a proprietary, in-house persistent object database that was read-only at runtime. We found that because of cache coherency issues, if any station used the in-process or local out-of-process server version, and that station had either write caching or packet burst enaled in Client32, the object reference table (a master index of the persistent objects established in the system) sometimes couldn't retrieve an object at one station if another station had at any time cached the object locally. Once this corruption occured, no reference into the object table from any station was reliable, and the problem remained until the Novell server was downed and brought back up, or all users logged out and fresh identical file copies were written to the server. No problem under the MS CLient for NetWare, or on earlier (pre 4.x) versions of
>NetWare.
>>
>>Things were even worse if compression at the server was enabled; noone could reliably retrieve any data from the compressed volume using standard Win32 API calls.
>
>Ed,
>
>Sometimes I think that we're in process of forming the "VFPDAN" (VFP Devlopers Against Novell).< g >

It's not just VFP developers. Might I suggest Developers Against Most Novell Upgrades? (DAMNU) < g >