Elgin,

I used to work with one-to-many reports, and I used to use the data environment. There was no end to the trouble I had trying to modify a report and clicking past all of the error messages, and trying to debug problems when the wrong table was selected.

Most reports are started from a form where the user chooses some type of criteria. In the CLICK() of the "go" button (or some method it calls) I SELECT all the data for the report, exactly the way I want it, into one non-normalized cursor. I also set up variables for the fields that show or hide depending on which version of the report I am printing. I never put anything at all in the environment, and never refer to the fields in the cursor as MyCursor.MyField, but rather just MyField. All that is necessary is to make sure that the cursor is the current work area when the report runs, which it usually is since that's usually the last thing that happens before the REPORT FORM... statement.

So, in the CLICK() of the button, the code would look something like this:

SELECT Parent.ParentFields, Child.ChildFields ;
    FROM Parent LEFT JOIN Child ;
    ON Parent.ParentKey = Child.ForeignKey ;
    INTO CURSOR ReportCursor ;
    WHERE < some criteria > ;
    AND < some other criteria > ;
    ORDER BY < some order >

*!* Some of my reports have changable titles
lcReportTitle = "Records meeting criteria"
*!* I have some fields that I don't always show, using Print When
llShowSalary = .T.

REPORT FORM MyReport TO PRINTER NOCONSOLE
USE IN ReportCursor

This method of approaching reports is also used by several other people who hang out here and do a lot of reports.

"I have to design this report to a specific format."
I'm not sure how using the report's environment or not would affect how your report is "designed" if by "designed" you mean the way the report controls, groupings, headers, horizontal lines, page footers, etc. are laid out. It would, however, greatly change things if there were a design requirement laid down by someone else to put data in the environment or whatever.




>Cindy,
>
>"Never make reports from related tables"? How do I design a report that is based on a one to many relationship? Do I create a view establishing that relationship between the parent and child tables, then place that view in the data environment of the report?
>
>I already have the parent and child views established in the form that will be calling this report. The form also establishes the relationship between the parent and the child views.
>
>Are you telling me to not use the data environment of the report designer? I have to design this report to a specific format.
>
>I think I can extract the data using a SELECT statement as you described below, but how do I use my report format and where does that SELECT statement go?
>
>Thanks
>Elgin