FPW hangs with REPORT FORM

[Zog1]

First, my apologies if this post turns up in another thread. I'm new to the fourm, and tried to post the problem as a guest a couple of days ago, but haven't seen a trace of it since. Now the problem...

In a given release of our application, When the user tries to print or view a particular report, their system hangs, and they must shut FoxPro down. To clarify, on another release, another report will cause the hang.

We have an app in which the report forms are a mix of DOS only, DOS and Win and Win only. This problem only arises with .frx files that have Windows records.

We are not using the project manager for our application; we distribute .fxp files.

The problem only occurs in FoxPro runtime. It does not reproduce in interactive mode.

Through pure luck, I found a way to 'fix' the problem, but it is not a fix in the sense that I changed any code or system settings.

For this discussion, assume that Master.prg is the master program file. The first time the problem occurred, by chance I recompiled Master.prg on my computer and the problem was gone. We assumed it was a problem with the devel manager's machine and worked from that premise, avoiding compiles on that box.

Then, a couple of releases later, the problem reappeared with another report. This time, recompiling on my computer created the problem, while another programmer's machine gave us the 'fix'. Hummmm...the third time we caught in pre-release and were able to 'fix' it again the same way.

Naturally the skeptical minds of the company determined that my end of the hall was smoking funny cigarettes. Despite our testing, it happened again on a client's machine, and none of our machines would give us working code. The skeptics spent several days tweaking memory, modifying code, playing with CONFIG.fpw, putting FLUSH commands everywhere, and nothing was working. Clients were warming up a bit, and I got a bit frustrated, so I decided to play with Master.prg again. I added two lines to end of it:

PROCEDURE Dummy
RETURN

when I compiled the problem was gone!

I don't mind doing some intuitive work, but would prefer to take a more reasoned approach to this. I am 100% certain that it will resurface if we don't figure it out, but I don't have a clue where to start looking. Any ideas?

 

[dgrewe]

This seems to be a reccurring problem with FPW2.6 running on Win9x and WinNT computers. There have been several threads on it in this forum, Comuserve and UniversalThread. Since the Keyword Search is still down in this forum, See if this thread helps you.
Title:"FoxPro for Windows2.6 Hangs With 100% CPU Usage"
Dated: 01/09/01
Thread182-22295
David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[Zog1]

Thanks for the quick reply, David. Unfortunately the link you included to the 100% CPU Usage thread didn't take me there. Tips for the newbie?

 

[Zog1]

I got to the recommended thread and it appears the programmers there are as confused as I am. There was a memlimit suggestion, but that's exactly what was tried here recently. It is irrelevant to the problem.

I can't see how adding a couple of lines to a program file that is remote in the program hierarchy from the one containing the REPORT FORM command would prevent 100% CPU ussge.

 

[csteenbe]

I have the same problem and I regret to say I can't also find the problem. My resolution is that I delete one or a couple of fields in my form and recompile. After that I put in again the field(s) what I have deleted and it runs!!!

However this will not solve my problem, I hope through your thread to get some answers.

 

[Zog1]

Me too! Your remark about deleting fields reminded me of another quizzical feature of this problem: The first time it hit us it only appeared if the user had modified particular forms and had removed four particular fields from the header band. With some 50 suspect forms, Our release testing for the problem is, as you can imagine, a nightmare, and we still missed catching it recently.

I suspect it is a bug in the compiler, but looking at that is way beyond my skills. I've studied 'good' and 'bad' .fxp files and felt like an archeologist looking at hieroglyphs without the Rosetta stone.

 

[mallee]

I have encounter this same problem a few times recently,
in each case it turned out to be data related. I think it
was unprintable trash in the file. On one occasion I did a
scatter memvar on an individule record and inserted in back into the file and it worked. More recently, I wrote a routine to scatter memvar and insert into a temp file, then
deleted original file and copied temp back to data subdir for all the files involved in the report. Worked fine.

Hope this helps you
HD

 

[Zog1]

Thanks, Mallee, but that's a no-go. What you're describing smells of a cache issue to me. The behavior I have is definitely not data related. I'm beginning to think it's maybe demons. My logic insists it has to be introduced quietly in the compile process.

CSteenbe's post seems to be the very thing. Nothing logical in his steps, but it works. --Zog

 

[zimbaliza]

I had the same problem a few years ago, running
under windows 3.11, was strange, only seemed to
affect some machines & didn't happen all the time

like you said didn't effect full fox, only runtime

I think I upgraded the printer drivers on the problem
machines & reinstalled fox (on mine)

only seemed to do it in printer runs.... i.e. printing
100 invoices off at once...

Hasen't come back for a few years is GONE!

 

[RazorbackHog]

Sounds very similar to the problem I have had for years. We re-wrote our 2.6 app in VFP and problem went away. Still have this problem in another app that has not yet been re-written. It does appear to be data related to me, I think index related maybe. I have actually written code to "fix" the locked up printjob by scatter memvar/insert from memvar then deleting the original records and re-printing. Works most of the time but not 100% effective. I have also had luck with rebuilding the files that are used for the printjobs by copying the structure to an empty file then appending records from the original. This also has helped but eventually the problem comes back.

 

[stuckwith26]

We finally after a long search found why we had this problem. It was data related as Mallee said it was above. Only in our case it was not garbage data in the table the report was printing from, but rather a structure difference in our table that was loaded into an array earlier in the program. The array was not used to print the report at all, but still is the cause of the error in our case.

 

[Zog1]

Thanks for the post, StuckWith26(like that's a bad thing). Your solution seems completely illogical, just as mine does. I guess I should have done a smoke-and-mirrors act when I 'fixed' it the first time, and become a local god. Zog is so smart! Yeah, right.

We did another release a few days ago, and I'm holding my breath. We have hundreds of reports, most of which can be run from several different 'locations' in our program, and any one of which might produce the problem at one location but not another, so it is a worry. The last time it appeared, you could only get it to happen if you reindexed a group of tables and then navigated to a specific report at a specific location. Sheez!

We've got our migration to Visual 6 about 90% completed. Maybe this problem will cooperate and remain behind in 2.6 land.