Multiple Detail Bands and without Data Grouping 1

[mstrcmtr]

Created 4 following cursors containing records of specific period

1. T_Sale (10 Records)

2. T_SaleRtn (4 Records)

3. T_Purc (7 Records)

4. T_PurcRtn (2 Records)

Problem:

Making 1 report in which Created 4 Detail Bands for 4 tables but there is NO Data Grouping on any field e.g. Code etc. so how can relate and skip setting of these tables for printing all records of every table in there respective detail band

 

[Olaf Doschke]

Multiple detail bands are only made for tables you can connect by SET RELATION/ SET SKIP, you never get into the mode of scanning first table, then second, third, fourth.

What you want is to chain 4 simple reports with each one detail band. That's possible with the NOPAGEEJECT clause.

Bye, Olaf.

 

[mstrcmtr]

NOPAGEEJECT clause is not helpful because in my case Total of Numeric Fields printing in Page Footer Band of every report

 

[GriffMG]

Alternatively combine the 4 cursors into one with a structure that can accommodate all the data needed in the report, use an indicator field to tell which cursor they came from and then use Print When expressions to get the right fields in the right detail band

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

You could also precompute totals and only print them in the last report. Notice a report also has access to whatever variables you define outside of it not as reportvariables.

You wouldn't be able to sum from different tables or cursors with a report variable anyway, as sequential workarea scanning doesn't work.

Bye, Olaf.

 

[GriffMG]

If you combine in one cursor, you can count and sum across the details within the report.

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Yes, Griff, but I was still thinking of keeping separate tables and chaining reports.

Combining cursors has 256 fields limitation, gets complexer the more different cursors you combine, may have unwanted overlap of fields, you need to detect groups anyway. since you can chain reports with NOPAGEEJECT, I consider it the easier solution.

Bye, Olaf.

 

[GriffMG]

True, but some of those fields will probably be common to all the cursors...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Olaf Doschke]

Well, and there could be unwanted overlap, eg same name different data type...
Separate reports, especially when you already have them, are easy to chain.

A difficulty is keeping report variable states. But there is the option to NOT release report variables, or not even make use of them. Precompute things without the report variable and calculations feature, which opens much more possibilities anyway, and then work with them in all or some reports, which you chain.

If you insist on using the few calculation types report variable offer you can set up normal variables first, init report variables with them via their init property, "On exit" of bands/reports store current values and restore them in the next report, if that matters.

You may see a design advantage in one report with multiple bands, but as they don't work as mstrcmtr thought, it also has advantages to be able to design simple reports you can then combine dynamically in whatever dynamic order and composition. There is no easier way than the sequential execution of simple reports, Relations are for 1:1 or 1:n relations, not for sequential chaining.

You could also think of word automation.

Last nor Least: If many fields are common (same name, data type and meaning), it's a very good case for report groups. Why avoid them? Especially if the data has equal structure it asks for another fieldholding a group number or other mark of groups.

Bye, Olaf.

 

[TamarGranor]

I wrote about the approach that GriffMG mentions, with an example:

http://www.tomorrowssolutionsllc.com/Articles/Multiple Detail Band Reports.PDF

Tamar

 

[GriffMG]

TamarGranor, that is exactly what I had in mind.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[Mike Lewis]

I agree with both Tamar and Griff. It's a question of using the best tools for the job. The report designer is best for formatting text (and images) and presenting it nicely on the page. SQL is best for manipulating the data, and getting it into the most efficient form for other processes to use.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads