Error 108 File is in use by another user

Several reindexing have occured.

You don't have a backup that you can use?

Of course we have a backup, however because the system was/is somewhat stable after the incident, users continued to enter data. Now that it's been a week, and the end of a month, it would be impossible to revert to a backup. We do run a test build also to help locate issues, a pre-event backup was pulled and place there. But it also appears sluggish after the 8 gig point is hit. However we have not seen the error 108, although not to many users are accessing it. Just mostly staff that are trying to troubleshoot the issue.

I can completely relate to your woes.  I am running a dataflex accounting system here.... :O

Perhaps this link helps?
http://msdn.microsoft.com/en-us/library/aa975932(VS.71).aspx

Have you reviewed your security permissions?  Perhaps something changed when you reestablished something?  I am shooting in the dark.  I hope a VFox Pro comes to your rescue.

Maybe it's time to convince the "powers that be" that it's time to upgrade?

This error is coded into the application and is not generated by VFP itself. It could be translating a VFP file in use error, or any number of similar issues the software knows about.

WhoHasNT - A tool to determine who is using a file/directory:
http://www.gadgetfactory.com/whohasnt.shtml

File Unlocker:
http://ccollomb.free.fr/unlocker/

Hope this helps

Actually that is a VFP error number, I just didn't recognize it. Regardless...

Regardless....?

Is it windows causing the problem or is it VFP causing the problem?

Hard to say, I can only recommend the tools I mentioned above. They will help identify the file and free it from the clutches of evil. hopefully :)

I know creepy magic, if those tools don't work.

Perhaps there are some .tmp files that are clogging the pipes?

Off point however the author only mentioned the software is VFP. But it is possible to still be using a SQL backend, right?

I hope each terminal service should have its own temp folder possibly not on the RAID drive then it should not cause error 108. This error means some problem in shared resources.

If there is SQL then some measurements on the SQL would be useful, as well. But I don't think so because error 108 is not obvious in client server environment.

pcelba:
"Error 108 can raise due to the fact the application is waiting for resources much longer than ever before and some timeouts are simply too short"  

I think you might have something here as the error occurs when the system is sluggish. So this maybe more of a server OS issue than a VFP issue? And BTW you're preaching to the choir on the mission critical app using VFP, I'd much rather it be SQL.

I just completed a sfc /scannow, nothing found there.  
I appreciate all the comments, keep them coming.

Is there antivirus installed on the server? You may consider exempting the vfp software folder.

Perhaps you should get some sort of deleted data recovery tool.  Like this:
http://www.recovermyfiles.com/

It's a tad bit "hokey", but it worked for me once.  I had to kill a medicine man to get it, though.

JF0:
The data files are excluded, but we finally shut down the whole service to see if it was affecting performance.

MrMintanet:
I've used recovermyfiles before, if you like a lot of generic names on recoved file it ok. But in this case we didn't really lose anything, we just have a slower server.
 

Perhaps you should upgrade the PSU?

If it is not problem of large FoxPro data then yes, I think this is more server or OS issue than VFP issue. Errors start rising after the crash. There is something wrong which consumes server resources more than before, so it is slower. It could be some hardware problem which is solved by OS adaptability but it consumes more time than before, it can be some OS patch or update (did you check installed OS updates?).

VFP has its own memory space on terminal service and 200 megs should be enough. Do you have some data size statistics to avoid large VFP data as the possible reason? VFP is able to use disk more heavily if data size exceeds certain limit. Did the application pass some stress testing?

And, sorry for the preaching :-).

pcelba:
Good points. The server did indeed take March updates prior to the crash. However they were removed after we realized there was an issue. I've sent a 6 hour preformance log to Dell hoping they might see something I've missed. I'll keep everyone informed.  

I've exhausted my ideas already, hope Dell has some fresh forces. The truth is any VFP application is possible to optimize and brute force is necessary for servers.

When I have encountered "File In Use" errors, I have used a tool which will identify who has that file in-use.    

The tool I use is  WhoHasNT  (http://www.gadgetfactory.com/whohasnt.shtml).    It will show the Windows login name for anyone who is currently using a file (of any type).

First I have to have sufficient Error Logging/Trapping in my application to determine which specific file(s) might be the problem.   And I need to determine where in the code the problem occurred so that I can more readily duplicate the problem.

 Once I know the file(s) I then start with that tool and if someone is found, then I address how/why/when, etc. and work to resolve the conflict.    If that tool does not show anyone using the file, then the OS is somehow 'confused' and telling VFP wrong info.   That is a much more complicated issue, but it too can be chased down.

Good Luck

I've seen situations with terminal server where a previous session cannot be reconnected upon a new login and it creates a new session (I don't recall the error message).  Is it possible that the TS session that was cutoff has never been properly terminated?  Does the error message and sluggishness problems happen only when the person who was online during the crash reconnects?

This issue was resolved by a complete wipe of the server and reinstallation of the operating system. A backup of the  Foxpro files were tested  (pre-crash) and also exhibited the same errors and freezing. So something must had broke in the OS during the crash. I awarded pcelba the points as he was right in determining the error 108 can be caused by sluggish performance on the server.

See the last comment for how we resolved this issue. Thanks!