Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Records Freezing due to Resource File

Status
Not open for further replies.

DaleFrench

Programmer
Sep 11, 2003
8
0
0
US
Hello again and I am sorry for kinda of double posting, but after experimenting I think I may have found a solution, but I am not sure. Here is my problem. I have a customer that sent me his data from a Worthless Check program we wrote(err My Dad wrote) in Foxpro 2.6a. His problem is that all the sudden many of his records keep locking up the computer when he tries to print any report from that record. Other records will work fine. He is on a network and the other computers do the same. So I download the data from my email.
Now after I unzipped the data, here is what happened. When I ran the program from within the command window of the langauge foxpro 2.6a none of the records froze the computer. Then I decided to make a shortcut on my desktop to the executable file. It was then that those records locked or froze the computer (had to CTRL ALT DeL) to exit. Everything was looking in the same directory. This same thing happens when I use other executables from other counties that used the same data in the same way. I also did foxfix and deleted and recreated the indexes - so the problem was not in the indexing or executable file. But why did it run fine from my foxpro languange envirement and not from the shortcut from my desktop? Well here is what I found out after much exploration.
The config.fpw file in my c:\fpw26 and my c:\base\wc directory(where my program is being run) are the exact same. RESOURCE IS SET ON. Now I SET RESOURCE OFF in the c:\base\wc directory and the records still freeze my computer from the shortcut on my desktop. Now I copy the foxuser.dbf file and foxuser.fpt from my c:\fpw26 directory and SET RESOURCE ON in the config.fpw file in my c:\base\wc directory and NOW I can view the records that I earlier couldn't. Problem fixed? I delete the foxuser files from my c:\base\wc directory with Resource still ON and Records Lock up again from running the program from my shortcut. I replace them and it works fine. I SET RESOUCE OFF in the config.fpw file in the c:\base\wc directory With the foxuser files still there and records freeze again. I set it back ON and it works fine. So I have a few questions:[dazed]
1: Can my solution for this customer be to tell him to delete any and all foxuser.* and config.fpw files from all his workstations and his server and then to replace them with my foxuser files and updated config.fpw file?
2: Can foxuser.dbf and .fpt files suddenly become corrupt?
3: The data looks fine to me but can it possibly be that he has corrupt records? He has over 51000 records, it would be immpossible for me to find all corrupt ones(if that is case)
4: Not really a question, but he runs the same program in another county that is networked and used, and he has no such problems. Executable File is the exact same.
5: What exactly does having Resource set off and on mean and why has it solved my problem on my computer with his data?

Any help would be GREATLY appreciated. Thanks in advance.






 
Hi DaleFrench:
Are you absolutely sure there isn't more than ONE foxuser .dbf/.fpt resource file on the path? Things can get REAL squirrlley if your application finds one file sometimes, and a different file another time.
Jerry
 
Hello Jerry, and thanks for response. Here is how my Dad wrote the path in the main proram in the project.

PUBLIC gcdbfpath
DO CASE
CASE FILE('security.dbf')
gcdbfpath = ''
OTHERWISE
gcdbfpath = 'i:\'
ENDCASE

I: is the start in directory's on all my customer's computers which are networked on drive I:. I am really unsure as to what you was asking but thanks for response.(I am still learning)

Still though, the records that I once couldn't see when I tried to print a report(no SQL) I can see now, Simply by transfering the Foxuser files from my c:\fpw26 directory to my c:\base\wc directory and also turne RESOURCE ON in my config.fpw file in that directory. So still one of my questions can I fix him by sending him those files?

Thanks Jerry[rednose]
 
Hello DaleFrench,

1: Can my solution for this customer be to tell him to delete any and all foxuser.* and config.fpw files from all his workstations and his server and then to replace them with my foxuser files and updated config.fpw file?

There is no doubt that having multiple FOXUSER.DBF & FPT files pathed into a user's application can cause strange things to happen. Eliminating this problem by making certain that only one copy is "visible" to the application is certainly the first step.

2: Can foxuser.dbf and .fpt files suddenly become corrupt?

Just like any other data tables the FOXUSER files can become corrupt, but there is much less likelihood than other tables which are repeatedly opened, manipulated, and closed by the application. Unless your application stores special color sets, or other unique information into it, you can replace the user's copy with a "virgin" copy from your system.

3: The data looks fine to me but can it possibly be that he has corrupt records? He has over 51000 records, it would be impossible for me to find all corrupt ones (if that is case)

There is certainly the possibility that there might be some corrupted records in the user's table - especially in light of your #4 below. Could it be that your report performs a UDF on one or more of a record's fields during printing? If so, then the hang might be occurring there.

In spite of a large number of records you could write a program to check for record corruption.

Or you could repeatedly run the report on just a few records at a time to check the program operation, the records, and anything else.

4: Not really a question, but he runs the same program in another county that is networked and used, and he has no such problems. Executable File is the exact same.

This tells us a lot. Using the process of elimination, it exonerates the application itself and points to a site specific problem.

Also, if I understand your statement, the entire application ran fine from your command window and then failed when run from your desktop shortcut. This tells me that whatever the site-specific problem is, you have the same problem at your site as the customer has.

It would be helpful to know specifically what the Target: and Start In: fields in the shortcut Properties has in it.

And it would be good to know what your CONFIG.FPW looks like. ( especially any RESOURCE=_______ )

Lastly it would also be good to know if your application has any code within it to establish/setup the execution environment other than the gcdbfpath code. Especially code that refers to PATH or RESOURCE, etc.

5: What exactly does having Resource set off and on mean and why has it solved my problem on my computer with his data?

The FOXUSER resource files are where FoxPro "remembers" things about how you (or your application) last ran FoxPro - where you opened a screen, a Browse window, etc. It also remembers things like Label formats, etc. With RESOURCE ON, FoxPro look to see if it has a previously saved reference to use. With RESOURCE OFF, FoxPro will go to default settings.

In summary it seems like there are still a number of un-answered questions, but you are on the right track to hunting them down.

Good Luck,
jrbbldr
jrbbldr@yahoo.com

 
jrbbldr, Thank you much for such an informative reply. You answered the questions I asked. As it turns out, I had him delete any and all foxuser.* files and config.fpw files from all his workstations and the server, and immediately he was able to print from the records that where locking him up before. After that I sent him a fresh copy of those files from my c:\fpw26 directory and told him to put it just in the main directory that the program starts from on his server. Hopefully, his problems are gone. I will keep my fingers crossed.

Thanks again[smile]

Dale
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top