Report is created too long

[novice001]

Hi all
I have a report that gives me info from one record of the table. It's not big, just one page, a few fields, some calculation fields, etc. Nothing too complicated. However, it takes very long time to generate it - sometimes 20-30 seconds, sometimes even a few minutes. I have Pentium 4, so it is pretty irritating.
The same report on the same record again is generated very fast, probably it is cached, or still in the memory, but if i do it again on the next record it still takes very long to see it.
Any ideas why that can happen? I use Paradox 10. Is it a normal behavior for reports or I do something wrong?
Thank you

 

[Guest_imported]

If the report is run straight from the tables, then it should run fast enough. However, if you are running the report from a query, or if the calculated fields require the entire tables to be scanned, then this will slow it up.
Another source of delay could be from using any option other than "Ignore data changes and continue" restart option on the report. Open the report in design mode, follow the menu Format->RestartOptions.
HTH

 

[footpad]

novice001,

In addition to OGriofa's thoughts, you may also want to look at the the following:

-- Are there group bands on the report? If so, then Paradox has to fetch all the data, sort it, and then determine what fits on each page of the report.

If you're printing query results, you can often work around this by sorting the data in your query and removing the group bands from the reports. (After all, why sort the data twice?)

-- Review your calculations for anything that requires Paradox to read all the data before rendering a report page. For example, it's common to want to print "Page x of y" in the header, so you know where you are in the report. Unfortunately, this forces Paradox to internally render the report in memoryin order to determine the total number of pages before it can render the first page. This can be time-consuming, especially if you have a number of complex calculations.

-- If you're using calculated fields to summarize groups of data, e.g. total number of orders for each customer and so on, you may find it easier to precalculate those total before opening the report. (Yes, this means redesigning the report to link in those results.)

The reason this can help stems primarily from the additional control you have over how those results are calculated. When you rely on Paradox to calculate summaries, you're never sure of how that process is accomplished. On the other hand, if you take control of that process, you can use the most efficient process avilable (e.g. TCursors, setRanges, and other index-based approaches).

Yes, this is a lot more work and a lot more research, however, if speed is the primary factor, it's something that simply needs to be done.

-- Finally, check where your data is coming from. If you're using a remote database, for example, you may be able to speed up the printing process by adding views (or stroed procedures) on the server or by using other common tricks for reducing the amount of data needing to be collected from the network before results can be printed.

In a similar vein, you may be able to reduce the printing load by "de-normalizing" certain elements of the table. For example, we're told that it's best to only store lookup ID's and then fetch matching descriptions when we need them (by linking the lookup table to the data table in the report). This is true, however, the practical effect of this is that Paradox needs to open the lookup table each time it prints a record from the master record. In certain network situations, this can be a tremendous performance drain.

The solution is to add a description field to the data table and make sure that the lookup table is defined with a Help and Fill / All Corresponding Fields.

In any event, problems like this usually stem from the amount of work that Paradox needs to perform to display the report as you designed it. If you can simplfy that design, you can often speed up the report a great deal.

Hope this helps...

-- Lance

 

[novice001]

The answer turned out to be very simple - the report is generated very fast and reliable on another computer. Probably the problem is in Windows XP that I'm using, or I just need to reinstall everything.
Thanks for help.