If you can open the report in Design mode, do so, and see if there is a VBA
module handling any events for the report. To determine this, open the
report's property sheet, and on the "Other" tab see if "Has Module" is "Yes"
or "No".
If it's "No" then the following does not apply and I have no additional
ideas at this time.
If it's "Yes" then open the VBA editor (on the menu line, "View" then
"Code") and look at the code for each event routine. Each event routine's
code will start with a line like "Private Sub xxxxxxx" and end with "End
Sub" and there will be a horizontal line between each (assuming there's more
than one of them).
Check to see if you have "Private Sub Report_Open" or "Private Sub
Report_Activate" event routines coded --- if so, see if a "Cancel = True"
statement is contained in either of these routines. This indicates that the
report is coded to sense some condition which will cause the report to shut
itself down during the open process. Alternatively, the routine can stop
the open process by using a "DoCmd.Close xxxxxxxx" method. See if either of
these routines are causing the report to be terminted in the open process.
And check if you have an event routine called "Private Sub
Report_NoData" --- if so, see if either a "Cancel = True" or "DoCmd.Close"
statement is contained in it. This indicates that the report is coded to
sense a "no data" condition and terminate when the input recordset is empty.
See if this is a possibility.
If you find any of the above, it's my opinion that proper programming would
result in a message being issued to the user ----
And while you're in the VBA code, make sure that each and every event
routine contains an "error handler". An error handler might be coded like
"On Error GoTo something_or_other" or "On Error Resume Next".
If an error exists and no handler is coded, the report will terminate.
An error handler like "On Error Resume Next" will ignore any errors. If a
statement causes an error, that error will be ignored and processing
continues at the next statement. This may or may not be acceptable.
An error handler like "On Error GoTo somthing_or_other" will cause Access to
go to a line of code labelled "something_or_other" if an error occurs --- at
that point, the error should be handled, or a messgae issued, or something
like that.
If you see any event routine without an error handler, you may wish to put
one there. At the top of the event routine, right after the "Private Sub"
statement, insert a line that says:
"On Error GoTo Err_Routine"
And at the bottom of the event routine, just before the "End Sub" statement,
code the following 4 statements (don't forget the colon on the second of
these statements):
Exit Sub
Err_Routine:
MsgBox Err.Description & Cstr(Err.Number)
Resume Next
Do this for any event routine that has no error handler.
Now compile and save the result.
Now run the report and see what happens.
Bob (@Martureo.Org)
