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!

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

Report Corrupting DBF and causing "Not Responding" problem 1

Status
Not open for further replies.
tkee

tkee

Programmer
Feb 6, 2004
55
US
I have a report in a compiled exe (FPW 2.6a with patches) running on Windows XP that has worked fine for a long time. Now I am having problems with the computer "Not Responding" whether printing or previewing the report from within the program. If I run the report outside the program with the same data it works fine. I have changed the data from a temporary file to a cursor to a permanent file with no ultimate difference. I have rebuilt the project and exe numerous times. When the report hangs up it corrupts the file, which in this case isn't a catastrophe since the data is created for the report, but I need users to be able to print these. I have tried it with 200 records and with 43 records thinking maybe if I broke it into smaller chunks it would make a difference. I'm to the pulling out hair point. It always works from FPW but never in the exe. The data is created by a query and remains fine until I try to run the report. If I skip the report and go back to the data it is still okay and will print manually in the report. I have dozens of other reports on the same system working fine, and this report works fine outside the exe. I also tried changing to another printer driver and recompiling everything with no luck. I have tried it on more than one workstation. Any ideas?
 
Sort by date Sort by votes
If I was guessing (and I am) I'd say there's some sort of UDF call somewhere in the report that Windows stops for security reasons when run from the exe. When you run from the IDE it somehow passes muster.

What's in there?
 
Upvote 0 Downvote
There is one question that I always ask when I hear something like: "I have a report in a compiled exe running on Windows XP that has worked fine for a long time. Now I am having problems".

That is: Before you made any changes yourself in an attempt to diagnose the problem, WHAT CHANGED?

If things used to run and now they do not, then something changed.
* New server OS
* New workstation OS
* New Virus SW
* New installation directories
* something...

Lets start by identifying what changed and then try to eliminate the variables.

Good Luck,
JRB-Bldr
 
Upvote 0 Downvote
JRB-Bldr Makes a good point think about what changed.

However......

You can also try this attack. How about writing a new simple version of the report, start off with just one field of information can you get that to work? If not chances are it is not the report but something before the report is called, but if it does work then save a copy of the working report and add a few more columns of information etc and try that. Maybe at some point it stops working, think of what was just added and you might get an a-ha. It is also possible that you will rewrite the report from the ground up and it works. Heck I have had things like that happen, e.g. never did figured out what was wrong, but I got the new rerport/program/etc to work in the end.

Lion Crest Software Services
Anthony L. Testi
President
 
Upvote 0 Downvote
Thanks for your suggestions. I don't think anything has changed. This program is on an old server that is slated for replacement in the near future. I don't know about the other workstation, but nothing has changed on mine and it does the same thing. I don't have any UDFs in the report. There have been viruses going around, but its strange that only the one report would be affected and on two different workstations at the same time. It bothers me because I always fear repetition if you don't find the cause, but I was told this morning that the report is to be replaced with something totally different immediately - for other reasons. So I guess it's been resolved in a different way.
 
Upvote 0 Downvote
The app runs fine if I don't call the report. It also prints dozens of other reports with no problem, a few of them hundreds of times a day.
 
Upvote 0 Downvote
Whoa, wait.... "hundreds of times a day" is language that waives a big red flag when it comes to FPW and reports.

There was a memory leak in the FPW RW that only manifested sometimes in some reports on some machines, but it caused all sorts of wacky symptoms. The only solution we ever found was to reboot the computer. (NOT just restart FPW.)

We had a reporting app that had an internal counter. After every <howmany> reports, it would call an API function to reboot the computer and auto-start the reporting app. It sounds like voodoo when talking about it, but the symptoms were observable. And solved with the reboot.
 
Upvote 0 Downvote
Dan,
good catch on the 100s a reports a day! I have never (nor have I ever heard of) pushing Fox to do 100s of reports a day. I would of assumed that it could do it, but finding out that it has issues also does not suprise me.

I am supprise thou that just exiting Fox every so often ( say 1/3 of the reboot counter ) do not fix it. Not saying you are wrong just suprises me.

Anyhow thanks for the info and I will put it in the back of my mind for the future!

Lion Crest Software Services
Anthony L. Testi
President
 
Upvote 0 Downvote
The workstations printing the numerous reports (individual receipts) are having no problems. The report hanging up is on workstations, including mine, that seldom print anything.
 
Upvote 0 Downvote
...call an API function to reboot the computer...
Click to expand...
For what it's worth, I have add issues with old Fox memory leaks and memory corruption since, well, forever. But exiting the Fox app then killing the 'ntvdm.exe' task from task manager, then restarting the app worked fine without the need for a reboot.
Of course, the 'kill' could be automated just as easy as a reboot.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Upvote 0 Downvote
For what it's worth, I have add issues with old Fox memory leaks and memory corruption since, well, forever. But exiting the Fox app then killing the 'ntvdm.exe' task from task manager, then restarting the app worked fine without the need for a reboot.Of course, the 'kill' could be automated just as easy as a reboot.
Click to expand...

It's the best we could do in NT3.51. :) For some reason, KillProcess wasn't effective but ExitWindows was. ::shrug::

I wasn't on that team. The problem was solved so I took their word for it.
 
Upvote 0 Downvote
Are you sure that the Report in the compiled program is the same report as you are running in command mode? I have made this type of mistake too often

Modify the report you run in command mode slightly, by adding a little text field, with no change in functionality. Recompile to ensure you are running the intended report
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

kyletreyfield
  • Locked
  • Question
VFP9 won't start because of &quot;insufficient memory&quot;
Replies
15
Views
414
Piotr Czekalski
Piotr Czekalski
ducklord
  • Locked
  • Question
VFP6 - &quot;Delay&quot; in changing DBF files file modified time
2
Replies
21
Views
335
Mike Lewis
Mike Lewis
TinyNinja
  • Locked
  • Question
Report Form print sizing problem
2
Replies
32
Views
1K
TinyNinja
TinyNinja
gbcpastor
  • Locked
  • Question
Export Foxpro 9 DBF to Dbase 5 File 1
2
Replies
22
Views
2K
Don Child
Don Child
Allwolfpackfan
  • Locked
  • Question
Convert Foxpro Memory Variable to a DBF
Replies
9
Views
337
Chris Miller
Chris Miller

Part and Inventory Search

Sponsor

Back
Top