asked on

Report not printing

I am using VB 6 Enterprise with Crystal
Reports 8.5. I am using the OCX control. On
the development machine, the report will
print fine when I execute the code. On
another machine, we installed the executable
and all of the associated dlls that Crystal
uses and the app needs using the application
setup wizard application. On this machine,
the report will not print at all. However,
other crystal reports that are in this app
will print from this machine.

The code that I am executing looks like the
following:
crysControl.DataFiles(0) = App.Path
& "\FDRdb.mdb"
crysControl.ReportFileName = App.Path
& "\rptMiscCashReceipt.rpt"
crysControl.SQLQuery = sSQL
crysControl.CopiesToPrinter = 2
crysControl.Destination = crptToPrinter
crysControl.PrintReport

Is there anything special that you have to
do to make PrintReport work?

The other reports that print correctly are
those that require user interaction because
they are previewed using the Crystal
controls.
The code is similar to:
crysControl.ReportFileName = App.Path
& "\rptInitialBill.rpt"
crysControl.WindowState = crptMaximized
crysControl.Action = 1

This application only uses the OCX control.

Thanks for any help.

Mike McCracken

Replace

crysControl.PrintReport

with

crysControl.Action = 1

In theory these are the same but I have better luck with the latter.

mlmcc

mnord

ASKER

When I change the PrintReport command to Action = 1, the users are getting a SQL server related error and the problem is that the database is actually Access.

mnord

mnord

ASKER

When I change the PrintReport command to Action = 1, the users are getting a SQL server related error and the problem is that the database is actually Access.

mnord

ASKER CERTIFIED SOLUTION

trkcorp

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Mike McCracken

What does your query look like?

You use sSQL in the program. There may be something wrong with it.

mlmcc

mnord

ASKER

trkcorp:

You answered this in the other group.

I didn't have the ODBC DSN setup on the test machine.

mnord

trkcorp

I suspected that, but you still might want to stick that error trap right after the .printreport because it has saved my bacon more than once, especially after it is installed on the user's machine and something gets squirrelly... Like I said, the print engine will very often encounter an error and "handle" it without ever reporting it to you. Result: darn thing doesn't work and it gives no clue as to why.