As so often, we are up against the seqence of processes that Crystal uses. If I've understood it correctly, the decision whether or not to print a section is made before the performance of any subreport that the section may contain.
![[surprise]](/data/assets/smilies/surprise.gif "[surprise] [surprise]")
Hence a section consisting just of a subreport is reckoned to be 'non-blank' even if the subreport will later return blanks.
I tried experimenting with some of my own data, an account with transaction records that might or might not be there for the last month. I also tried using shared variables, and found the values of the original subreport were kept until the subreport was processed again.
It then occurred to me, why not perform the transaction processing twice, in two distinct subreports, the first time as a dummy that would print no data. By knowing the answer ahead of the actual subreport printing, control should then be possible. And it was,
![[profile]](/data/assets/smilies/profile.gif "[profile] [profile]")
at least when I tried it.
Subreport A sits on details a, and returns the account number for the transaction record, if it finds any transaction records. If it doesn't, the account number from a previous account will be kept.
Subreport B sits on details b and shows transaction details. But details b has a suppress formula, that applies whenever the account number for Subreport A is different from the current account number. And this worked fine.
It is a bit of a fiddle. You cannot suppress Subreport A, otherwise Crystal refuses to process it and the values never get updated. What you can do is have it blank and put it on the same line as the account details, overlapping something and doing no harm.
I hope that this method is general enough to work for your report as well. Madawc Williams
East Anglia
Great Britain
