Date:  05/13/2014 08:16:02 AM Msg ID:  004698
From:  FoxWeb Support Thread:  004693
Subject:  Re: File is in use by another user.
Given the intermittent and brief nature of the problem occurrences, there must be something locking your tables for short periods of time and then releasing them. It's hard to know what it is, but you can approach this as a normal multi-user VFP issue. All data access in FoxWeb scripts uses native VFP code, so there will be no FoxWeb-specific complications.
 
It's hard to say what is causing the slowdown after a reboot, but it could be that the server is still in the process of starting and initializing its various services. How long does this last?
 
I suggest that you keep the buffer memory size at about 100 MB per channel. VFP was designed to work with less powerful hardware and actually gets worse performance if the buffer memory size is too high. Note that FoxWeb 4.6 changed how the setting is treated. Versions prior to 4.6 divided the setting between the various channels (e.g. if you entered 100 MB and had 4 channels, each channel would be configured with a buffer memory size of 25 MB). This is no longer the case. Each channel uses the actual value that you enter in the settings. This means that for your v 4.3 server you should enter 100 MW * <number of channels> in the FoxWeb configuration, whereas in your v 4.6 server, you should enter simply 100 MW.
FoxWeb Support Team
support@foxweb.com email
Sent by Martin Martin on 05/13/2014 06:02:20 AM:
 
 
- look like isolated occurrences. (but it's related to the number of user online...when very busy)
I just ignore this error cause I don't see how to fix it, and it's always occuring 2, 3 times a days.
- no, I do not have killed channel in the log(server1) but (server 2) yes
- Yes and No.  
 
I have 2 servers with foxweb installed.The script and table are not the same. One is foxweb 4.3, the main task of this server is to verify login and as no running app on it.
the error occuring 2, 3 times a days.
 
On my other BUSY server, I have foxweb 4.5, this server as VFP application running on 24/7, playing with the same table of foxweb. 
on this server, some day I don't have error and some day, the error occur more than 10 times during the days.
 
Both server report this strange error. 
 
One thing I notice is, after a reboot, the script are very slow. I have an indicator at the bottom of the page telling me how much time the server take to execute the script. The first time I run a big script I get 7sec. but the secound time I run it, it take 0.4 sec. (this first long delay look like related with the error)
 
Is this can be the zise of the BUFFER MEM. SIZE in the ControlCenter? I'm currently have 1000MB 
 
I run 15 channels on a windows server 2008r2 64bits, 16 meg ram. Intel Xeon 3gig (2processors)
Both server are identical 
 
thanks for you Help
 
Martin 
 
 
 
 
 
 
 
 
 
 
 
Sent by FoxWeb Support on 05/12/2014 04:06:10 PM:
  • Do you usually get multiple of these errors within a short period of time, or just isolated occurrences?
  • Does the error go away by itself, or do you have to do something, such as restart FoxWeb, or reboot? 
  • Does fw_start.log indicate that any channels are killed and restarted around the same time as these issues?
  • Is the table in question ever opened by a regular instance of VFP (as opposed by FoxWeb scripts)? Could it be that this is causing the table to be locked? VFP has the Open Exclusive option enabled by default.
FoxWeb Support Team
support@foxweb.com email
Sent by Martin Martin on 05/12/2014 01:33:37 PM:
 
- YES, it's an intermittent error that happens once in a while. It's happen more often when we have a lot of activity.
- No I don't close the files (DBF) myself. The close table option is checked in the configuration. 
- YES, I'm using the default error handler
 
 the error is 108 ..
 108 File is in use by another user. 
 
 this error I don't have it  
 109 Record is in use by another user. 
 130 Record is not locked. 
 1705 File access is denied. 
 
- NO I n'ever open file exclusively.
 
 In all my programs I have this lines on top:
 
SET EXCLUSIVE OFF
SET REPROCESS TO 5
 
 
Martin 
 
 
 
 
 
 
 
 
 
Sent by FoxWeb Support on 05/12/2014 12:39:08 PM:
You stated that you start to get the error when you have a lot of activity. Does this mean that you continuously get the error once you get it initially, or is it an intermittent error that happens once in a while, but goes away shortly?
 
You also stated that the file is always open. Does this mean that you don't close the file yourself and that you have disabled the Close Tables option in the FoxWeb Control Center?
 
A USE statement should only cause error 108, if the underlying file is locked. Do you ever open the file exclusively?
 
By the way, the FoxWeb Error Handler has some special code to deal with errors 108, 109, 130 and 1705. If one of these errors is encountered, it continuous retrying the statement that caused the error, before logging it and returning an error message. This suggests that the problem is in place for at least 4 seconds and is not a result of a momentary lock. I assume that you are using the default error handler, rather than replacing it with your own code. 
FoxWeb Support Team
support@foxweb.com email
Sent by Martin Martin on 05/12/2014 11:49:10 AM:
HI, 
 
I try to solve this problem for a long time now.
When I have lot of users and activity, I starting getting error that make no sense for me :
 
ERROR 108 :  File is in use by another user.
 
When I go to the source code at the specified line number, it's a simple USE statement.
 
   USE LOGIN IN 0 ALIAS LOGIN
 
I'm only use FREE TABLE so there are no .DBC 
This file is always open. There are no way to open it exclusively. This script was executed over 20,000 times per day.
The error seems to be completely random in time and always on the a USE statement (first 2 or 3 lines of the program)
 
So, is it possible, if the same program was call on the same foxweb channel then foxweb run into problem?
Is this related to CLOSE TABLE option in the configuration tab ? 
 
How can I solve this?
 
Thanks for your Help
 
Martin