Program randomly crashes when printing. Help! 2

[Jadden200]

Hello all. I have posted about this similar problem before and now it is coming back to haunt me more severely.

I have a customer that has been using one of my FoxPro 2.6a Windows application for years. Suddenly, the program will randomly but conistantly lock up on them when printing.

This happens when they are entering new records and trying to print(warrant, letter, anything) and also with records currently in the system(taking payments, etc.)

To narrow down the issue, I downloaded all their data and ran it on my computer using the same application. We all use Windows XP.

The same records locked up on me when I tried to print or preview them. Also about every 5th record I would add would lock up when trying to print.

Now on to the wierd things: I would pack the database, and would be able to print the records that wouldn't print. I thought that was the solution until those same records suddenly were unprintable again.

I have deleted the cdx's and rebuilt them. I have run foxfix and fptfix. I have searched for garbage in the databases. I have Resource set off in the app. I deleted every config.fpw and foxuser file on my computer. I checked report corruption. Nada. No reports work on 'corrupted record'

These reports use no querys they just pull directly from the fields in that record.

Why would something that has been working so long suddenly do this with no changes to app?

This does not lock up my computer. Only the app.

This happened before when two different offices where using the same app. Office 1 suddenly started having this happen. Office 2 had no problems.

It seems like I solved the issue by packing and/or deleting all the foxuser files.

Not working this time.

Sorry for such a long thread. But I really need some advice here.

 

[DSummZZZ]

It sounds like you've most of the basics. If there is some sort of hidded corruption in the tables, I would think those would be fixed using the utilities you mentioned.
But you may have to do something more drastic like copy the data to a text file delimited or something, then append it back into brand new tables. There could be some embedded character causing grief that may be overlooked by those utilities.

But on top of what you've already tried, have you made sure the printer driver is good and current?
Have you tried different screen resolutions? (Believe it or not, it matters).


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Jadden200]

Thanks for the tips DSummZZZ.

Didn't think about screen resolution, but if that where the case, why do the other records print? Still worth a looking into though.

I did copy database over using the Copy To with cdx command. Then renamed it back, that didn't work. Have yet to try to copy to text delimited and bring it back.

Added a config.fpw file
Resource is set off
Changed Memlimit to 90,8192

Seems to help. But every other 7 or 8th new record added will lock up when printing any report for that record.

Printer Drivers? Its doing it on my end and the customers networked end involving three seperate workstations and a server. My printer driver is up to date. God I sure hope it has nothing to do with printer drivers.

I don't know. Like I said packing and deleting all foxuser files and fpw files has worked in the past. Just not working now. Resource is set off in the app and config file.

Will try to copy to text file and send it back, like you mentioned.

Any more ideas would be greatly appreciated.

Thanks.

 

[tesar]

Jadden,
try
report form myreport to myfile.txt
!cmd /c copy myfile.txt /b lpt1
Tesar

 

[dbMark]

Do you know exactly where the crash is occurring? Have the code write to a log file so you can narrow down exactly where in the code it stops logging? Is it within the report form code? Or afterwards? Will it fail if you're in debug mode?

Another idea, build a looping program to go through each field in each record and display any non-text characters, especially any CHR(27) or below. Lots of those are "invisible when viewed and CHR(0) is especially nasty.

I think the 2.6a DOS version would probably work better from the older command.com rather than cmd.exe. I guess the Windows version doesn't use or access either one? The problem is that FoxPro 2.6a for Windows was a bit of a hybrid between DOS and Windows. It's over 10 years old and based on 16-bit code. Visual FoxPro is so much better with 32-bit code.

 

[dbMark]

When examining the table, you might need to use FOPEN() to look at everything inside by bypassing the standard "table" interface. I say that because the standard USE command does not let you truly look at the contents of the DELETED() setting, which is actually the true first character in each record. By using FOPEN() you can look at that "field" too.

 

[dbMark]

Over in the dBase FAQ section I wrote a table fix program at faq290-4606. There might be some dBase commands that would have to be modified to work in FoxPro, but it was helpful for me.

dbMark

 

[Jadden200]

First of all I would like to thank you all for the very helpful replies.

Tesar, I have not done what you suggested. I am a unclear as to what you mean, but I have documented it. Thank you.

Dave, Thank you so much. In the end, I did do the 'Drastic measure' and exported to txt delimited file and appended it back (all 54000 records). So far that has seemed to work. Then packed all. I can now print those records that I couln't print ealier. So far, in testing, I have adding over 50 records with their database, and printing every report, and so far, no Lock ups. I will be sending the data back over tommorrow with hopes that it is fixed. They have been 'down' for two days now. Thank you very much!

Mark, Thank you for sharing some things I would have never dreamed of thinking about. I am saving this post in my favorites for future reference, due to the rich information it yeilds.

To answer a question of yours: What was happening, was that when a new record was entered, it would randomly but consistantly lock up when printing a report from that record.

Ex: This is a worthless Check program designed for District Attorneys Offices. When a merchant brings in a bad check, they must immediatly file into the system and print out a warrant and or complaint. When they click on the print warrant button, the program files everything into the system(Warrent printed date, etc.) But it would just lock up after the command:

IF gl_print
REPORT FORM d14_warr NEXT 1 &prt_opt NOCONSOLE
gl_print = .F.
ENDIF

gl_print stems from a Print or Preview screen. If a report where to freeze on a particular record, any and all reports for that record would do the same, even after computer was restarted.

After I did the import and appending and packing. It seemed to have cleared the issue. I will know more tommorrow after I send the data back to her.

I am going to check out that link you sent me in the thread to hopefully learn more, and thanks again for the information.

Thanks all.

 

[DSummZZZ]

Glad you made some progress.
That 'drastic measure' makes me think there were some funky characters in the data. How they got there - no telling. But at least the translation to a flat text file helped.

Hang on to those tables and when you get some free time, you can look into them closer and maybe find out what character(s) it/they were. You may be able to modify one of the dbf fix-it tools or even write your own routine to fix it if it happens again.

Best of luck!


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm