Report Printing VFP9 Sp2

[boanrb]

Hi Friends,

I have quite a scenario. My report (rep208z.frx) displays correctly showing all details when you issue REPORT FORM REP208Z TO PRINTER PROMPT PREVIEW command in my app.

But the moment I hit the printer button, the output comes out without the records in a way to indicate the frx printed a blank or the eof() record.

I tried issuing the SET REPORTBEAHVIOUR TO 80 command just before the REPORT command but to no avail - it still prints a blank.

All labels show correctly but all my cursor fields show blanks. Dates show " / / " and the others just blanks.

Again - The preview is just very perfect. Only the printed copy or the PDF copy, when I print to PDF drivers, behave like this.

It's a scenario where "What You See Is Not What You Get"

Any Ideas? Just moving from VFP6 and I am really lost on this - kindly assist I pray.

Benson
Data Centre

 

[TamarGranor]

Not sure how it would apply in this case, but I spent way too much time the last couple of days working on a report that worked great when I tested it, but not inside my application. Turned out the problem was SET EXACT. The report in question needed SET EXACT OFF (because it had relations set to give multiple detail bands), and the app was setting it ON.

So, not sure how EXACT would make a difference between preview and print, but figured I'd throw it out. Maybe some other SETting is the issue, too.

Tamar

 

[Olaf Doschke]

I wonder what is different in the preview run and the print run.

If you REPORT FORM ... FOR condition or WHILE condition, the second run resets the initial record position, but what about more complex situations like the relations tamar mentions? Even despite of EXACT On or Off I can imagine resetting the record pointer of the report driving main alias could be too less to repeat the run.

So what about the experiment to skip the preview, does the PDF come out, if you don't create a preview at all? In case of a PDF the PDF itslef mostly is shoed after it's creation anyway, so isn't that Postview enough in that case?

Bye, Olaf.

 

[JRB-Bldr]

Actually I think that I'd try printing to a REAL Printer as a first test (even if the results were not quite as you would like) and not the PDF print driver.

Then if that also failed it should have eliminated the various print drivers from the source of the problem.

But if you were to get a reasonably good output from a REAL Printer, then I'd look at issues with the PDF Print driver.

Good Luck,
JRB-Bldr

 

[boanrb]

Ok friends. I have picked some other things from this discourse which I will try and let you know.

Thanks a lot all of you.

 

[boanrb]

JRB-Bldr,

I printed to a REAL printer, PDF printer and Ms xps Doc - same results. So I think the report itself is the problem, or the environment.

Thanks nonetheless.

Benson

 

[boanrb]

Dear all,

Ok. The problem was that the form calling this report was running in "Private Data Session". When I changed to "Default" the report behaved normally.

Am sorry that I had not checked this as suggested by JRB-Bld. I only checked in the Report Form itself.

Now the question is why would this happen?

But I am really grateful for ALL your support.

Benson

 

[Olaf Doschke]

What matters is the data being available in whatever datasession the report runs.

The form having private datasession just means it starts a new datasession and every other form or report started from it using default datasession uses this same datasession.

So private datasession does not mean it's only for the form, it just means adding a further datasession. And also default datasession does not mean datasession 1, but the active datasession.

The private datasession f the form launching the report can be the culprit, if the report needs data from a previous datasession, but in itself a private datasession form can launch a report working on the data that form maintains. This itself is no reason the report may not work.

Bye, Olaf.

 

[boanrb]

Much appreciated Olaf.