Error 111 FoxPro DOS 2.6 with Windows XP

[TimoP5]

Hi,

First of all, I want you to excuse my English. Here's the problem. We are using FoxPro DOS 2.6 for several years. Everything was running fine until we decided to upgrade the server to a Windows Server 2003. Now everything is working correctly excepting 1 program. This program is reading a few dbf files (maybe 200 files) to print a sales report. So basically, it's a loop doing "open the file, read the file, print data, deleted printed data, close the file". Since we are running Windows 2003, it's not possible to go trough all the process. FoxPro freezes saying "Error 111, Not able to write in a read only file" (This is the English translation of the French error message). This problem is strange because it's always freezing at a different line in the code. We did some test. Here are the results:

1-FoxPro on a Windows 2000 server, Windows XP Pro Client: Everything working perfectly.
2-FoxPro on a Windows 2003 server, Windows 98 SE Client: Everything working perfectly.
3-FoxPro on a Windows 2003 server, Windows XP Pro Client: Let's say 90% it's freezing saying error 111, and 10% it's working OK.

It seems that the problem is coming from Windows XP on the client side. We tried to add FILES=150 to config.nt, we tried to use command.com instead of cmd.exe, We tried to work with all the different compatibility modes, we tried to adjust memory size with no success.

Right now, we are lost, so any help or clue will be really appreciated.

Thank You

Francois Paquette.

 

[dbMark]

Does the XP client have read/write/modify rights to those tables?

Shared folders: Remember, when a directory or folder is shared, you have to go into the Permission button to enable writing. The default is to only allow reading. Make sure your user or his group is listed there with rights to read/write/modify.

Folder and/or file security rights: Are these different users on the different computers? If so, have one of the users who you know it works on his computer go and log in to the problem XP.

I wonder which files it's having problems with, are they the same ones all the time, or random ones? Are the files on the server or on the local computer? If it's on the server, verify the user or his group does have read/write/modify rights on that table/memo/indexes or folder(s). If it's a work or temp file on the local computer, then it could be a rights issue of the person logged onto the XP computer. If the user doesn't have Administrator rights, XP will not let them write to the root directory of the computer. Does your program write tables or other files to the C:\ root directory?

Another idea is that something about the table has changed and the program tries to change the table but can't because it's been opened with SHARED or maybe NOUPDATE. Was the CDX (table's compound index) changed by another database language so that FoxPro wants to rebuild the index? It needs exclusive access to do that. Or maybe the language driver is different?

"Opportunistic Locking" on the XP to server can affect this. There's also a bug with XP clients that was fixed in XP Service Pack 1. Are you up-to-date on security updates?

Physical problems: Sometime a faulty NIC (network interface card) or netowrk cable is at fault but that's pretty rare.

Hard to really say what your fix will be, but these are some ideas to check out. When you do get it fixed, let us know what did it.

dbMark (in Ohio USA)

 

[TimoP5]

Thank you dbMark!

At the begining, I was testing a "limited" account user. To prevent problems coming from the rights, now I'm doing my tests with a "Domain Admin" account, and I verified that this account has full control on the folder where the bdf files are. So I don't think that the problem is coming from the read/write/modify rights.

The problem occurs with random files. Same error (error 111), but different line in the code and/or different file.

The files are on the server (We access those files from a mapped drive \\server\foxdata) and some "temp" files are on C:\windows\temp. All users have full control on this folder.

The files are open "Exclusive".

We are using Windows XP SP2 and automatic updates is enbaled on the client computers.

We are using 4 differents computer to fix this problem so I don't thing the problem is coming from the Network card or cable.

1 Dell Optiplex GX 280 P4 3GHz, 1 Dell Optiplex 170L P4 2,8GHz, 1 Clone Celeron 2,4GHZ and 1 Clone Celeron 2GHz with Windows 98 SE.

On the Windows 98 SE client, it's working perfectly. Everytime, it's doing what it is suppose to do.

On the Windows XP clients, it's only working correctly 1/10.

I'm not familiar with "Opportunistic Locking" so I'll read on that.

For me it looks like a memory problem, maybe be with ntvdm.

I think we can open a ticket directly with Microsoft, But I think they will say that the problem is coming from the code..... If any of you had a positive experience with Microsoft, please let me know.

Thank you again, I'll continue to work on it and let you know what is going on!

Francois.

 

[dbMark]

Important question: You did not give samples of the lines of code that failed. Was it when the tables were being opened? When a record was appended? Or when data was being written? An index opened? Or other places?

Beware of using computers faster than 3.0 GHz. Recently some users have reported that they've had problems with FoxPro either at or exceeding that speed. Probably some internal timers were designed long ago not expecting a computer to go that fast. (There was a FoxPro fix for computers going faster than 300MHz many years ago, but I wonder if that "fix" only bumped the limit from 0.3 GHz to 3.0 GHz...) Search the forum for these reports.

Windows NT, 2000, 2003 and XP all emulate DOS, not natively as the older Windows do, and as you now know, it does not emulate perfectly.

Even if you don't figure out the exact cause of your problems now, you can continue to use Windows 98se or Millennium. Long term, I'd suggest you decide to upgrade to Visual FoxPro 9.0 which just had Service Pack 1 beta released. All you need is to buy one copy per developer or whoever compiles the code and you can provide unlimited compiled EXEs or DLLs for all your other users. (The VFP development program must be installed on a Windows 2000, XP or newer computer but any Windows 98 or newer computer can run the compiled applications.) If your programs are not too complicated, a simple port can finally move you out of the DOS world. There are 5 VFP forums here:

http://www.tek-tips.com/threadforum.cfm?lev3=27

 

[TimoP5]

Hello,

Thank you bdMark!

I did a search for "Opportunistic Locking" and I found a solution for my problem! I add 2 new entries in the registry :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableOplocks REG_DWORD value = 0

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled REG_DWORD value = 1

Now it's working perfectly!!!

Thank you again dbMark!

Francois Paquette.