Well, I really would rather not have to re-run all my record-selection queries every to print a report. These are big databases -- I'm looking at about two million records in the finished product -- and queries take time. The user has already defined the record set he wants. I would like to be able to use the existing filtered table.

However, the SET SKIP does seem to be the key. Although you don't want SKIP to be on when viewing the form (you need to advance once for each child record to move the parent), you DO want it on for the report. (Interesting difference here. I'm not sure I understand it.) The following test code does seem to work, at least in a small and well-defined system:

*-- test of sharing the data environment
*-- between a form and report,
*-- to avoid having to spend time duplicating queries
*--
*-- in this system, imNeg is the parent of imPrint,
*-- in a 1:M relationship
 
public vFPtr

*-- open form with reference pointer
do form forms\imnegfrm name vFPtr linked

*-- move to form's private data session
*-- so we can make sure the report is using the same DE
set datasession to vFPtr.datasessionid

* -- now let the report use the form's data environment
select imNeg		&& probably not necessary -- it's already selected
set skip to imPrint	&& allow multiple children in report

*-- add a NOWAIT to examine things from the command window
report form reports\imrel_r1 preview

select imNeg 		&& just making sure...
set skip to		&& preserve normal behavior in form

*-- control returns to form
*-- in an actual program, 
*-- we would also want to return to the same record

Can anyone tell me if this is dangerous?

Thanks,
BEW