>> The new version FoxFire support sent hasn't fixed the problem we hoped it would.

We're still getting critical errors on reports with large result sets.
We changed the date range filter from serveral months to one month and
it still crashed. Then we changed the filter to one week and it ran.
One day ran too. Back to one month and we crashed again.

>Fatal Error Exception code C0000005
>called from getProvdName() line 2790 in mc_procs.prg


'getProvdName()' is our function but there's nothing wrong with it. It works fine in the smaller runs. Sometimes other functions of ours are in the first line of the call list. This became a problem with SP3. Prior versions ran ok. Any ideas? Thanks. <<

Hi Joe,

I'm not really surprised an updated version of Foxfire! didn't help since I suspect the problem is not Foxfire! related. I won't fully stick my foot in my mouth yet, but given that the error is occuring in a non-Foxfire! function would indicate the problem is somewhere within the general FoxPro reporting apparatus.

After specifying report options within the Foxfire! interface, Foxfire! simply builds and executes FoxPro SQL and a FoxPro report. Therefore, I can't imagine anything proprietory that Foxfire! is doing such that a report would work for a narrow filter range and not for a wider filter range.

However, the best way to try to narrow these things down is to simply run a test in FoxPro. Cut-n-paste the Foxfire! generated SQL into a separate program and execute it. Try all your different date range filters. What happens? If the Sql executes o.k. with all filter ranges, then next try running the result through a Foxfire! generate FRX. Foxfire! simply executes a:

REPORT FORM reportname.FRX PREVIEW

... where "reportname" is the name of the FRX.

Does that execute o.k. with your largest result set? If all that works then we'll need to take a closer look at your function a see where there might be some collisions between it and the Foxfire! environment. Typically problems result from the function clobbering some alias or memvar that Foxfire! expected to be open. IOW, you have to be very careful when you use your own functions that the Foxfire! environment is saved and restored upon exiting the function.

Whereever the cause lies, we'll try to help with a solution. Perhaps you can e-mail the function in question and I'll have a look at it.

Bill