Different groups of fields on different sub-summary parts

[DLS]

First of all I am new to this forum and am looking forward to participating.

Lets see if I can explain this problem. I have a solution I am designing for a police dept. Each case is a record in the Case Log database. I have a "line items" database with several relationships to it from the Case Log db in order to be able to enter an unlimited number of offenses, suspects, witnesses, complainants, victims and motor vehicles involved with each case. I need to run various reports so I have one line items file instead of one for each of the above. Offenses and each Person Type are displayed in its own portal on its own layout with a "Tab" type of interface.

Problem: I am trying to put together a sub-summary report that will first list a group of fields unique to the Offenses with that info. There may be one or more Offenses. Then a group of different fields for Persons involved(1,2,3. etc) with unique info. Then a group of different fields with Motor vehicles info involved. Since there are fields that may not have any info in them they show on the report. Does this make sense? What I really need is to have more than one body part with it's own sub-summary which is not an option.

I have designed the report using portals in the Case Log db but you know that portals don't print accross pages well and I am still limited in the number of Offenses, Persons and MV's that can be printed.

Any ideas? Am I missing the obvious or am I just trying to do something I can't?

[ April 15, 2001: Message edited by: DLS ]

[LiveOak]

Having all the different related data for a suspect in the same file doesn't really help much. There are really a couple of options. 1) Create a set of calculated fields to show the correct data for each record type (if you can reasonable define such a set) and use these plus subsummaries in your report. 2) "Build" the report into a blank file. This file might have fields "Text 1", "Text 2", etc. chosen just for their positions on the layout. using scripts, these fields would be populated with data to create whatever report you wish. Kind of like building the report as a text file, line by line. Each record in this new file is just a line in your report.

-bd

[DLS]

bd-

Thanks for the response. I think I know what you are saying but I'm not sure I have made my problem clear. I am having to "mirror" a standard report format that is required by other local officials. Text areas with names for the info. I call a group of them "field blocks". I am not able to have a "generic" field/name layout. the report has to be something like this:

I have these "field blocks"

Header with Case Info from Case Log db

Offense # 1 (fields/names unique to the offense for the case)

Offense # 2 (fields/names to the offense for the case)

Offense # 3 (fields/names to the offense for the case)

etc.

Person # 1 (Suspect) ( other fields/names unique to the person involved)

Person # 2 (Witness) ( other fields/names unique to the person involved)

Person # 3 (Complainant) ....

Person # 4 (Victim)...

etc.

Motor Vehicle #1 ( other fields/names unique to the mv involved)

Motor Vehicle #2 ( other fields/names unique to the mv involved)

etc.

Synopsis (one field)

Footer

All the above fields except the Synopsis field exhist in the "Line Items" db. There may be numerous Offenses, Suspects, Victims, Witnesses, Complainants and Motor Vehicles per case. All of this info is related to the same Case Number in the Case Log Database.

I have a different relationship set for each of the above in order to allow for data entry into unique portals on different layouts through a "Tab" type of interface.

With a standard sub-summary report with for example 4 records in the line items database (one offense, one victim, one witness, one suspect) I will get my offense info and then 4 empty "field blocks" before getting my other info.

I'm still thinnking of your suggestion of building the report in another file but I'm not sure what you mean.

Thanks again