So don't use it.

We don't. Then again, our application has used a third-party report writer for end-user reports for 20 years. Our only reporting requirement from VFP is status reports, result/exception reports from processes, etc., and those reports survive just fine with REPORTBEHAVIOR 80.

The one place we might benefit from the new enhancements is in printing checks, but that process is working so well from Maine to Hawaii I'm a little hesitant to upset the apple cart by introducing a change for no reason other than making a change.

But the moment we need a feature the old reporting engine can't provide but the new reporting engine can, I'm there and if it takes longer then that's the price we'll pay.

Seems like a simple equation to me.

Dan

>Thanks, Colin. We always remove printer information from the report. We've been doing that for years. I understand about paying a price. But this price seems to high. They've paid a lot of attention to speeding development, but it's not worth it at the cost of runtime sluggishness.
>
>Dana
>
>>Dana -
>>
>>In addition to what the others have said, make sure you are not saving the printer environment information with the report.
>>
>>VFP9 differs from VFP8 in that it referencs some newer printing DLLs in Windows (VFP8 uses some that were deprecated long ago!) and these have a tendency to hit the network looking for network printers when they really don't need to. Removing the printer driver information from the FRX can sometimes make a difference.
>>
>>As for new features vs speed, well, I think every programmer understands that you can't get something for nothing.
>>
>>- Colin