allan,
Both.
regards
>Andrew,
>
>Sorry, forgot to ask...
>Is the sp3 to be applied on workstations, server or both?
>
>>Hi Allan,
>>This looks like you are being caught in a Delayed Write that caught me on W2K - I suggest you apply SP3 ASAP - it fixes the delayed write of some VFP files. Al Doman is the expert in following this problem thru - i think.
>>HTH
>>>The directory is backed up * immediately * before the program.
>>>The program is then run and dbf's are disappearing on a random basis each time the application is run.
>>>They do not re-appear afterwards.
>>>They are then successfully restored from the tape backup.
>>>
>>>>>DBF tables within a database have started disappearing from a client's network.
>>>>>The configuration is VFP 5 runtime, W2000 sp1 on the workstations and server.
>>>>>Although we haven't run the program in debug mode we are relatively confident that the PACK command is failing.
>>>>>I would appreciate any other ideas before I suggest that the client have a third party run network and hardware diagnosis (big $).
>>>>>Thank you in advance.
>>>>
>>>>
>>>>Are the tables actually vanishing? Or are you just getting occasional "Table does not exist" errors? If it's the latter, then yes, it could definitely be the PACK.
>>>>
>>>>In general, any time you use the PACK command, you need to be certain that no other clients will be attempting to USE that table while the pack is in progress. A good rule of thumb is: Don't PACK a table unless you have exclusive use of the entire database.
>>>>
>>>>Why? Let's look at what happens internally during a PACK. The steps (roughly) are:
>>>> a. Create a new table with a temporary name.
>>>> b. Copy non-deleted records to the new table
>>>> c. Un-USE the original table
>>>> d. Un-USE our new table.
>>>> e. Delete the original DBF/FPT files.
>>>> f. Rename the new DBF/FPT files to the original table name.
>>>> g. USE the table (exclusive).
>>>> h. REINDEX the table.
>>>>If other clients are attempting to USE this table (with SET REPROCESS AUTO), they can interrupt this process at several points. For example, what happens if, between steps (f) and (g), another client jumps in at just the right instant and USEs the table? The PACK is now blocked, because we can't regain our exclusive use of the table, and it leaves us with an outdated index. Or between steps (c) and (e), another client could get use of the old table before we are able to delete it. Or between steps (e) and (f), the other client would get a "Table does not exist" error.
>>>>
>>>>Because PACK is deleting and renaming files, it cannot maintain constant locks on those files for the duration of the process. This leaves PACK inherently vulnerable to multiuser contention issues.
>>>>
>>>>Now, if the tables are actually vanishing (and not reappearing 10 milliseconds later), then it probably isn't caused by the PACK command, unless there's a network issue preventing step (f). Were access rights changed to disallow renaming of files?
>>>>
>>>>-Tom
>>>>
>>>>This post is provided "AS-IS" with no warranties, and confers no rights.