Divide by Zero with patches Fox 2.6a W2K

[DanJV]

We just installed a Windows 2000 network with our Novell network. We are using a Novell gateway to get to the foxpro programs on our Novell server. We have several applications compiled in Foxpro 2.6a, and the all start and run. Only a few of the reports give "Divide by Zero or Overflow Error" messages. Most work fine. I have applied the Patch26.exe and if I understand right DZPATCH is for 2.6. Any ideas on what might be wrong?

From what I have been able to figure out, the line of code it fails on is:

REPORT FORM &m0cmddr.mawfwo NOEJECT TO FILE &mWinPrint

&m0cmddr is the path of the report form mawfwo and mWinPrint is a temp file that we print to. Then we copy the file to the printer in another procedure.

It doesn't appear to make it past the Report Form before I get the divide by zero error.

 

[rgbean]

The speed patch is strictly for the start up. If you are getting a Divide by Zero elsewhere, it's a whole different problem. Normally when it has to do with reports, the first thought is the notoriously bad printer drivers that HP put out. (They neglected to reset the FPU back to the right mode!). See about getting updated drivers, use the MS supplied drivers or "downgrade" to a compatible driver.

Rick

 

[DanJV]

Rick,

Thats the other part that confuses me....we used the Windows 2000 drivers to set up the printers. And, other reports print to the same printers. It just doesn't make any sense to me at all. Admittedly, our print to text file method of printing is less than efficient, but it does work except on this particular report. I know ALL the different reports have not been checked, but this one is the only one that chokes. Any other ideas? I can't find anything different about this one, but theres gotta be.

 

[rgbean]

Dan,
I'd "zero in" on what's different about this particular report. Are you using some unusual font? Are you printing any graphics? Are you doing some internal calculations that are different than normal? Debugging reports is no fun, but not much different than other debugging.

Rick

 

[DanJV]

What baffles me about that is we send the report to a text file and then copy the text file to the printer. I think (if I understand things correctly) that doing this throws out a font or graphics issue, doesn't it? There are no graphics, only text. I will look it over and see what I can find.

Dan

 

[DanJV]

Looks like I need to add some additional background. We have a few machines still running Foxpro 2.6 for Dos. All reports are formated in Foxpro for Dos for compatability. When I transport the report to Foxpro for Windows, the divide by zero/overflow goes away. This also prevents the remaining Dos people from working.

When I look at the report, it has some float as band stretches, center vertically, and 3 simple calculations ((x+y)*w). I couldn't see anything wrong with anything on the report, so I tried removing fields one at a time and still no luck. There was one report grouping and I removed it and still it failed. The Dos reports work in other places, just not here. Does this give you any more clues?

 

[rgbean]

Dan,
When I worked on a dual-platform app (DOS & Windows), I made separate reports for the two environments. Then in the code, I just had code like:
IF _DOS
REPORT FORM &m0cmddr.mawfwo NOEJECT TO FILE &mWinPrint
ELSE
REPORT FORM &m0cmddr.mawfwox NOEJECT TO FILE &mWinPrint
ENDIF

Where 'mawfwox' is the Windows version of the report.

Rick