As well as what's been said, I'd add:
a) If possible, get rid of unwanted records in the select statement rather than suppressing them
b) If the report is going to be run a lot, take a look at the SQL generated by your code. If part of the selection isn't there, that means it's not being done on the Server and will be done slowly. I had a report that speeded up vastly when someone replaced a selection based on several date-fields with the same written in SQL. E.g.SUBSTRING("INAM01"."Kfield", 1, 3) gets sent to the server and thus produces a much faster return than LEFT({INAM01.Kfield}, 3)
c) Regarding subreports, the SQL Query (Database->Show SQL Query) will execute once. However, if that same report contains any subreports, then the SQL Query of the subreport(s) will execute as many times as it is triggered depending on what section the subreport(s) is/are placed.
d) On the other hand, Subreports make a lot of work for computers, but save time for humans. You decide which is more important for your particular circumstances.
e) Learn the best uses of running totals and summary totals.
Running totals allow you to do clever things with grouping and formulas. They also accumulate for each line, hence the name. The disadvantage is that they are working out at the same time as the Crystal report formats the line. You cannot test for their values until after the details have been printed. You can show them in the group footer but not the group header, where they will be zero if you are resetting them for each group.
Summary totals are cruder, but are based directly on the data. This means that they can be shown in the header. They can also be used to sort groups, or to suppress them. Suppress a group if it has less than three members, say.
![[yinyang] [yinyang] [yinyang]](/data/assets/smilies/yinyang.gif)
Madawc Williams (East Anglia, UK)
![[yinyang] [yinyang] [yinyang]](/data/assets/smilies/yinyang.gif)