This document is an attempt to gather in one place as much information as possible about issues related to printing from SQR for Windows directly to a printer (without having to separately send the report to the printer after the SQR program has finished executing).
This latest version of this HOWTO will always be available in the SQRUG web site library.
This is a very rough draft. If you have suggestions for improvements or if you have found other solutions to this problem, please contact me at the address above.
This document was generated using SGML-Tools.
In order to understand the reasons direct printing from SQR for Windows causes so many headaches, it is necessary to see how SQRW has evolved.
In the early days of SQRW, printing was simple. During program execution, the output ".lis" file was generated directly as each page of output was produced. There were no temporary files and SQRW had "knowlege" about the Windows printer drivers installed on the system.
These .lis files were basically straight text, with the possible addition of printer-control codes that the SQR programmer had specifically coded into the output.
For these versions of SQRW, if you wanted to cause the report output to show
up directly on a printer (rather than in a file on your hard disk), you could
take advantage of the fact that Windows/DOS had the special "files" prn,
lpt1, lpt2, and lpt3. By passing SQRW the the -f option with
these special file names, you could cause it to send its report directly to
the printer. However, SQRW itself had no idea that the files were special, and
treated them as if they were normal disk files.
Starting in v3, SQR added support for report layout definitions, graphics, bitmap images, and other advanced features. When these features are used, the ".lis" files can no longer be straight text, but instead must be in a format that allows advanced control of the printer. For this purpose, SQR now includes various printer drivers to generate output for specific types of printers.
Also needed to support the new advanced SQR features was an "intermediate" printing file. SQR uses this file, which usually has an ".spf" extension, to store the output of the SQR report in a common format that can be used by any of the printer drivers, and which allows SQR to do things it couldn't do when it had to generate the output file immediately as it was printed by the report.
(For example, SQR now includes a last-page command that allows you to
put the page numer of the report's last page in your headings, as in
"Page 1 of 14". Since this number is not actually known until the
report generation is complete, it's not possible to support
the last-page command using the immediate-generatation method.)
In order to use these new features, the user has to tell SQR which printer
driver to use. This is often done by specifing the -printer:XX
option on the SQR command line, but can also be done using the
declare-printer, declare-report, and use-report commands.
Normally, the user does not have to worry about the SPF file; SQR
generates it automatically when needed, simply replacing the ".lis" extension
of the report file with ".spf" (or just appending ".spf" if the report
file has no extension).
Non-windows versions of SQR support HP LaserJet®, PostScript®,
and (for SQR v4
and above) HTML printer drivers. SQR for Windows has additional support for
the "Windows" printer, which is the default printer driver as configured
in the Windows Printer control panel. The Windows printer allows you to
send your SQR report output directly to any printer that has a Windows printer
driver (which includes many printers that aren't HP LaserJet or PostScript).
It also allows you to print to any printer accessible from Windows, even
if it is not "attached" to one of the Windows/DOS special files
(lpt1, etc.).
The common problems with direct printing from PeopleSoft stem from the
fact that PeopleSoft generally uses the "old" method of sending output
to the printer. That is, normally when you select the "Printer" Output
Destination from the Process Schedule Request ("green light") panel
(and you have selected "Server" as the Run Location), PeopleSoft puts "lpt1"
in the File/Printer box, and then when you click "OK" it invokes
SQR with -flpt1 option. This works just fine -- until SQR (for any one
of the reasons mentioned below) needs to generate an SPF file.
As I mentioned before, when you use the -flpt1 "trick", SQR does not know
that lpt1 is a special file. If it needs to generate an SPF file,
it follows its usual rule of adding ".spf" to the end of the report name.
However, Windows/DOS still treat the file "lpt1.spf" as a name for the
printer. Thus, two things happen:
The following is an incomplete list of things that will cause SQR to generate an SPF file. (This applies to SQR on all platforms, not just SQR for Windows.)
-keep or -nolis options to SQR.last-page command.declare-printer, declare-report, etc.). (Note that you
will be forced to use these commands if you use the graphic or
print-image commands.)
Unfortunately, for many PeopleSoft installations
using the -printer:wp SQR option (as required
for the solutions given below) triggers another problem: most
versions of SQR 3 for Windows
were compiled before Windows 95 was released and do not support
-printer:wp under Windows 95.
This problem can show up in two ways, depending on the version of SQRW you are using. In both cases, the report will actually complete executing (updating its status to "Success" in the process monitor, for example), but the attempt to print the report to the printer will fail.
The exact list of errors will vary, but you'll get something like this:
(SQR 6619) Cannot access the default printer's driver. (SQR 6601) Cannot allocate the device context for the default printer. (SQR 6602) Failed to start printing the document. (SQR 6608) Failed to select font Courier New. (SQR 6603) New-page (start) failed on page 1. (SQR 6608) Failed to select font Courier New. (SQR 6604) New-page (end) failed on page 1. (SQR 6605) End document failed. SQRW: End of Run.
In these case, you won't get any error, but all that comes out of your printer is the first page of the report.
The recent versions of SQR for Windows (version 4.x) do not have these problem, but apparently there are no versions of SQR 3.x that work. If you can't upgrade to v4.x, you'll probably have to find a Windows NT machine (either client or server) to run on if you want to use -printer:wp.
The simplest solution to this problem is to avoid generated the .SPF file. If you can, simply avoid doing those things that trigger the SPF file (see the list in SPF File Triggers) for those programs that run on the Windows machine, and you won't have to change anything else. (For PeopleSoft sites with non-Windows NT servers, you should be able to run these programs on the server instead of the client, as long as the printer you need to print to is connected to the server.)
As far as I know, this is the only solution officially supported by PeopleSoft, for any version of their package.
This solution is also probably your best bet if you are running Windows 95 and cannot run a Windows-95 compatible version of SQR. (If you are getting the SQR 6619 errors and can't upgrade SQRW, this is your only option. If you are getting the "first page only" error, see Simple Solution below.)
You can also "avoid the issue" by printing to a file instead of directly to
the printer. Once the file exists, you can copy it to LPT1 yourself (e.g.
from a DOS prompt window). Or you could add -keep to the end of the
File/Printer box, which will cause SQR to keep the SPF file it generates
(in addition to your LIS file). You can then view and print the SPF file
using SQRWV.EXE (which is found in the same directory as SQRW.EXE).
-printer:wp to work for individual Process Definitions
If you really want to use the new SQR features in a report that you need to run on a Windows machine, and you want the output to go directly to the printer, you'll need to do a little more work.
The basic idea is that you want to cause PeopleSoft to send
the -printer:wp> option to SQR, and to put its output file
in a normal file (not in lpt1) so that it can create
the temporary file. As long as the version of SQRW that you are
using is compatible with your version of Windows,
this should allow SQRW to print directly to your printer.
(Note that if you have the "first page only" problem with your version of SQRW,
you'll see that show up here. If you are really desperate, you can work around
this problem by running the new-report command every time a new page is
generated.
Since you will be directing your output directly to the printer, this will
not cause multiple output files to be generated, as it normally would.
However, it makes each page a separate print job. Doing this does
work around the "first page only" problem, but may have undesirable side
effects, especially if you are printing to a shared network printer. )
First, you will probably want to do a quick test to make sure that the changes described below will work in your environment. You can also use this approach for "single shot" report runs where you don't want to (or can't) change the Process Definition.
In the Process Scheduler Request ("green light") panel, be sure the
Run Location is "Client". Select "File" for the Run Output/Output
Destination. (Note: you don't want to select "Printer"; if
you do the Printer/File box won't have the path you want.)
The Printer/File box should now contain the path to your normal output
directory (at many sites, this is specified as %temp%\).
Add to the end of this path a space, followed by "-printer:wp".
Now fill out the rest of the panel as usual and kick off the report.
This should cause PeopleSoft to invoke SQR with "-f%temp%\ -printer:wp" as part of the command line options, and (hopefully) your report output will show up on your printer.
If the test above works, then you may want to edit the Process Definition
for those processes that need to use the -printer:wp.
Advantages of this approach:
Disadvantages of this approach:
set wpprinter=-printer:wpin everyone's autoexec.bat files. (You'll probably want to set this in the same place that SQRFLAGS and other PeopleSoft-related environment variables are set.)
%WPPRINTER%". (In later versions of PeopleSoft, you may be
able to skip the first step, and enter "-printer::wp" into
the Process Definition box (notice the double ":"). I have not verified
this; let me know if it works for you.)
Notice that the report now shows up on the printer all the time, even though you don't select "Printer". In fact, if you do select "Printer" and "lpt1" is put into the File/Printer box, the report will abort with the SQR 6003 error (and therefore actually it won't print).
Similarly, the report can no longer be executed on a (non-Windows NT) server,
because "-printer:wp" is not valid on other platforms.
A more complex solution for sites that have many reports which need to
be executed using -printer:wp involves defining a new Process Type
(say "SQR Report w/Graphics") in the Process Scheduler. Rather than
configuring overrides separately for each Process Definition, you simply set
each of the processes to have this new process type.
Advantages of this approach:
Disadvantages:
The details will be added in a later version of this document.