ABORT RETRY FAIL in Foxpro 2.6 for DOS

[linhawaii]

I am the Network Admin for a company. We have a Win NT 4.0 server with approximately 30 - 40 users running some custom written Foxpro 2.6 DOS applications.

I am currently fighting a losing battle with my onstaff programmer who can not solve a problem we are having and blames the problem on the server. She is comfortable in DOS but is not Windows (98 or NT) knowledgable. She also is trying to work with programs that she did not code from scratch, she continues to try and "patch" code that was originally written by someone else over 10 years ago.

The problem:
All users get an "Abort Retry Fail on Drive G" error while accessing the custom written FoxPro apps. (It slowly spreads across the server, everyone doesn't get the error at once. )
(G is a locally mapped drive on the workstations and points at the share on the server called "Data&quot.

Then if you terminate the Foxpro and re-enter the program it works fine again.

Solutions that I have tried:

Moved all of the workstations to running Foxpro locally and changed the batch files that call the program to reflect that change.

Added files=150 (was files=99)and buffers=50.

All of the files in the shared Data directory, users have Full control of. (This was done per our programmer)

Changed the local config.fp to point locally for all of it's resources.

I keep trying to tell our onstaff programmer that something in her programs is causing the error because while Foxpro will give you an error and stop working, all other shared resources on the server (ex: files) continue to work.

I am not a programmer but I am trying to find a solution because it does not effect all of my users.

ANY SUGGESTIONS would be greatly appreciated. Thank you.

 

[ramani]

Hi,
I suggest you following...
1. Set the file attribute for all the FoxPro*.es? as +r. Also the runtime applications can be set to +r attribute.
2. Tell the programmer to create a resource file for each user and not use the default FoxUser.*. The way to set it is..
a. COPY basic FoxUser.* files to myFuser.*
b. Then put the following codes..in the starting lines of the programme...
myFUser = SYS(3)
COPY FILE myUser.DBF TO myFuser+".DBF"
COPY FILE myUser.FPT TO myFuser+".FPT"
SET RESOURCE TO (myFuser)
c. At the quiting place.. final quit to DOS prompt.. add the lines
SET RESOURCE TO
DELETE FILE myFUser+".DBF"
DELETE FILE myFUser+".FPT"
This cleans up the files system.
The idea behind is that.. each user will have his own resource file.
3. Keep the directory as trim as possible without a large number of numeric or such unwanted files, which will grow as more and more of these accidents take place. This could create bottle necks for file reading.
4. If the users can have their temp files directory in their local drive (can be set using CONFIG.FP) the performance will increase.
Hope you get some solution from above.
Best of luck ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK

 

[linhawaii]

Thank you so much for your input. I am having a very difficult time in trying to keep my users up and running with all of our FoxPro problems.

I will let you know if she is able to implement any of the solutions that you have suggested.

Our programmer is also in the process of converting our FoxPro 2.6 for DOS to Visual Fox and I am sure that you will see me on this site asking about problems with those programs as well.

Thank you again.

 

[dgrewe]

Ymtlax
Ramani's idea will work but there will be one bad side effect. If the users do not properly exit the program there will be many temp files in the application directory on the file server. Eventually these files will eat your lunch in network/application speed performance. I did it a different way by using a file named the same but in a location unique to the users, Such as thier local hard drive or network user directory.

In the example below the BIDSYSCF.xxx is a renamed FOXUSER files configured the way I want the enviroment to be for that application.. The fcTempDir is the unique directory for each user (in my case "c:\temp\&quot and the fcSysDbf is the location of the application databases.

do SetFcmem && declares all f* Memory Variables
if !file(fcTempDir+"BIDSYSCF.FPT&quot
use (fcSysDir+"BIDSYSCF.DBF&quot shared
copy to (fcTempDir+"BIDSYSCF.DBF&quot
endif
set resource to (fcTempDir+"BIDSYSCF.DBF&quot

This way every FoxPro application can have a different enviroment file on the users hard drive and the temp file do not collect as a result of improper exit. If you want a new config file every time you start the application, remark out the if and endif lines.
David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[linhawaii]

Thanks David for your input as well.

As I stated before, our programmer is less than experienced in a Windows environment and I am having a terrible time in keeping the users up and running in Foxpro.

I have noticed that Foxpro seems to lockup users when they are accessing a set of Foxpro library files that are on the server. (EX: D:\data\Operate\Lib\CLR_CODE.FXP,CLR_FUNC.FXP, PRT_CODE.FXP,SET_ENV.FXP)

(The user can Terminate the Foxpro Window and re-enter the program normally.)

I have asked our programmer to look into putting those library files local, but have yet to hear back from her.

Any ideas on what to do about these library files.

Thanks again.

 

[dgrewe]

Without knowing how the application is written, It will be hard to answer.

If the path to the library files is hard coded in the program ("D:\...&quot , moving the files will have no effect.

If the files are found as the result of a path statement in foxpro, You just need to get the programmer to change the path statement line

If the files are called by a memory variable, then the program must change the memvar

if the paths are stored in a database and that info is moved to memvars at the start of the program youhave it made, just change the database fields and put a copy of the lib file there.

I use the last method

http://ibs.internationalbid.net/home/dave/code_html/setfcmem.html

David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[linhawaii]

Thanks again David,

I wish I could tell you more information, but the programmers keeps all of her source code on a separate server.

I know that if I could get access to the code (which I have tried to ask for and was told I didn't need) I would have a better idea of what to do.

In the meantime, I have given your suggestions to the programmer and hopefully she will take the action necessary to correct our problems.

Thanks so much.