Hi Joe,

Well I'm going to describe a **possibility** here...

When write-behind is enabled on HDs the HD (adapter?) will return a 'completed successfully' to the write request EVEN THOUGH IT HAS YET TO BE WRITTEN PHYSICALLY TO THE DISK!!!

We know that VFP does at least 2 writes for every new table record - one for the record itself and one for the table's header. There can be more if FPTs and CDXs are involved.

Suppose that a key table in the system was updated with a new record but something failed with (one of) the physical write(s). You would have real trouble on your hands.
Now you shouldn't go thinking that this would mean that you have a flakey HD. I guess it/they are new in your case. I just installed a new PC 5 days ago and neglected to change the settings on my 3 HDs. Within 24 hours of running - and not even a VFP program but a Word document - I got a message to the effect 'cached data no longer available. Data may be lost'. This reminded me about the write-cache settings (actually called 'synchronous transfers' on these HDs). I disabled on all of them and no 'event' since!

So I'd say disabling write caching is ultra IMPORTANT and can come up with a throretical scenario that can explain your symptoms.

good luck


>>What was the nature of the "crashes"???
>>
>>Was the fail exactly at 6pm and is there something scheduled to run at that time on the same system?
>>
>>Does the new server have write-behind caching DISabled on the HD(s) where the data is stored?
>>
>>When you moved it back, did you copy the data over?... Sounds like you did.
>>
>>Were there ANY changes to the VFP app. in transitioning to the new server?... ANYTHING at all?
>>
>>good luck
>
>Hello Jim... at first operators reported it seemed to be 'freezing' or 'crashing' when they hit the SAVE button in the app... then over time they were falling like flies, people were crashing/locking/windows errors at any point in the app.
>
>Not sure on the write-behind cashing DISabled on HD of server, I will check into this. is this important?
>
>no changes to software... here is a more detailed account of what happened by our server guys:
>
>On Tuesday, February 15 at approximately 9:20 PM EST, Seth contacted me and said that HLC was having problems with IPC. He said that a few users began having problems saving then the issue got increasingly worse, IPC was down and Tom was onsite. Van conferenced myself, Seth, Chuck , and Tom together and I dialed in to begin diagnosing the problem.
>
>The first issue that came to mind was the Opportunistic Locking setting that we had to set on all of the Windows NT 4.0 servers running IPC in order to help reduce table locks. I checked HLCPCS01, but Opportunistic Locking was already disabled in the LanManServer\Parameters key in the registry. We rebooted HLCPCS01 and had the clients try to use IPC. Some of the clients were getting illegal operations (Windows errors). Tom tried to use the Batch Import PC which failed by simply exiting out of IPC. At this time the IPC guys were not seeing errors in the error logs for IPC and we had no errors in the event log on the server. Chuck ran a database validation and verified that the database was good.
>
>After exhausting our resources, we decided to copy the IPC data back from HLCPCS01 to LCDN01. I backed up the IPC and IPCCMM directories on the old server and setup a robocopy job to get the current data back to LCDN01. I then modified the group security on LCDN01 so that the appropriate users from the HOUPCS domain would be able to write to LCDN01\IPC. During the robocopy of data, I checked the Microsoft website and found that there are two places that have to be modified to disable opportunistic locking based on the clients connecting to the Windows 2000 or 2003 server. Even though we had copied the data to the old server, we thought it would be worth a shot to try the additional Oplock setting on the new server. When the data copy was complete, I created a OplocksDisabled registry entry in the MRXSMB\parameters key and we rebooted HLCPCS01. Tom tried to use the IPC batch import machine pointing to HLCPCS01, but it failed so we decided to begin using IPC on the LCDN01 with current
>data.
>
>When Tom tried to point the IPC batch import machine to LCDN01, he received the same failed result. Although the database verification was successful, we came to the conclusion that there has to be some corrupt data that is causing the problem so we cut back to the IPC data from Sunday on LCDN01. The shop floor had already been down for over 3 hours and we did not want to take the extra 30 minutes to copy Sunday's data back to HLCPCS01. Once the file security was verified, I opened up LCDN01\IPC and Tom was able to complete a batch import. IPC users began using IPC and all appeared to be fine with the exception that all of the data since Sunday is not present in IPC currently. Seth and Chuck will be able to get the data from Monday and Tuesday back, but it is going to take some time. Once the users verified that IPC was working we ended the conference call and decided to regroup tomorrow (today as I compose this message).
>
>One thing to note is that through all of this, the IPCCMM users did not have any issues and they are working on current data. The regular IPC is the only one with missing data. Another bright spot in this is there is still hope for IPC on the process control domain dc's, in particular now that the additional oplock setting is changed. I believe that since the database was already "corrupt" the users were having problems getting in after we changed the settings on HLCPCS01.
>
>This probably seems confusing, but that is probably because it is 2 AM and I am whooped. Right now what matters is that the shop floor at HLC is up so we'll look into this more tomorrow and go from there.
>
>
>
>
>
>
>
>
>
>>
>>>Hope someone has some insight into this.
>>>
>>>We recently transfered a very large Fox 7 App from WINNT server to WIN2003 server. It seemingly ran fine for 2 days. Then last night at 6pm all foxpro clients (50+) were crashing during save, crashing on reads, crashing on just sitting there. All other applications (including another Fox 7 app) on this server ran fine.
>>>
>>>We ensured Op-Lock settings were disabled.
>>>
>>>We checked our errorlogs.. nothing!
>>>
>>>We validated the databse... valid!
>>>
>>>We rebooted the server.
>>>
>>>We kicked everyone out, started it up again, same problems.
>>>
>>>We moved the entire app and DB back to the old WINNT server. Same problems!!! Does this mean something is corrupt, and validate DB is not showing it?
>>>
>>>We archived this badboy, and then reverted back to backup of 2 days prior before the server move, on the old server... all is running well.
>>>
>>>
>>>Anyone have any insight into this?
>>>Thanks