Hi,

Packing and reindexing at the end of every day **could** be your problem!

You say 'for about 3 weeks...'. Was something added to the server around that time? Does that thing(s), if added, also run when your VFP application is running?

I see 2 possibilities ASSUMING it started at some relatively discrete date/time:

1) Contention on the HD(s) with something newly added that is in use at the same time;

2) Something has caused the HD to have wide 'gaps' between DBF/CDX/FPT files that are used concurrently by your application.
Assuming that your daily PACK/REINDEX actually finds at least 1 record to PACK (else it really does nothing), then some big file(s) added around the time the slowness started (and themselves remain static) is a likely problem.
ALSO, if someone ran a DEFRAG around the time the slowness started then that is most likely your problem.

In my opinion defragging or PACK/REINDEX are bad practises from a performance point-of-view, This is especially so if the application files are all on a HD that is NOT used by other applications, but also applicable to a shared HD environment.

By definition a shared VFP application will ALWAYS write fragmented files in day-to-day use. And virtually all applications writing records to different tables at any instant in time is writiing records that are RELATED TO EACH OTHER. So as each file grows to require a new sector the OS will (typically) start on the next available large free space. As many files grow into new sectors those sectors are BESIDE EACH OTHER on the HD.
When you PACK/REINDEX or defrag you then separate EACH FILE (each table and each CDX and FPT) by the entire 'width' of the table. Worse still, the CDX or the FPT **could** end up at the opposite end of the HD.

Some things to think about.
Good luck

>Hi All,
>
>Packing and Reindexing is done at the end of every day.
>
>The network is protected by up-to-date antivirus which has not reported any attack.
>
>SELECT is not an option as there is need for updates. Views could do yes but it still does not explain to me why this is happening all of a sudden. Is it something to do with the sizes.
>
>Network speeds are 1.0Gbps. Larget table is 30,240KB with Records: 249,710. Fields: 18, Length: 124, Index: 2. This table is also the most dynamic in terms of deletions, insertions and updates.
>
>Regards,
>Richard
>
>>>Dear Saviours,
>>>
>>>I have a situation that requires a solution urgently:
>>>We have a database situated in a Winows 2000 file server. About 25 users access the various VFP tables from their WinXP or Win2000 stations. Their mode of access is live browsing on the tables. Majority activity include viewing of records as results of a SET FILT command given from the command windows. The tables are of varying sizes. The largest has abut 250,000 records.
>>>
>>>For about three weeks now, we have witnessed a decay in access speeds. The database has been confirmed to be valid but for some reason, on and off, psecific users suffer extemely slow response to the SET FILT command or any other access. This is so much so that at times it ends in the users PCs hanging.
>>>
>>>So far we have confirmed the the problem is not localized to the PCs at the workstations. We have also confirmed that it is not tied to network or local user profiles. Different users at different times tend not to be able to work.
>>>
>>>Anyone: Kindly give us pointers of where the problem is. It has been OK for almost 5 years and it is the first time that we are experiencing this. Is it something to do with FoxPro share limits? The data is growing...
>>
>>Reindex and see if that helps. Let us know.