Error
Hi,
Any clue as to why I might get a runtime error 216 followed by an access
violation after executing a ReportBuilder report. Delphi 4 RB6.03.
The objects I've used are a Delphi table accessing an Advantage dbf. A
datasource, a DBPipeline and a ppReport. This is a simplified version of a
more extensive report I need to add. I've simplified this to try and
isolate the cause of these errors.
I've added a single table, tabular report which displays three records to an
existing form. The simplified report displays the 3 records, and I can
close the form containing the report. When I close the main application I
get the errors.
Any ideas of where I can start troubleshooting. Also is there a preferred
method for opening the datasource for the report. This report program first
creates a data extract table, then should execute the report. So I open the
table, then the pipeline after the extract table is created, but prior to
running the report. Afterwards, I close the pipeline, then the table after
the report executes.
Thank you very much,
Mike Malinowski
Any clue as to why I might get a runtime error 216 followed by an access
violation after executing a ReportBuilder report. Delphi 4 RB6.03.
The objects I've used are a Delphi table accessing an Advantage dbf. A
datasource, a DBPipeline and a ppReport. This is a simplified version of a
more extensive report I need to add. I've simplified this to try and
isolate the cause of these errors.
I've added a single table, tabular report which displays three records to an
existing form. The simplified report displays the 3 records, and I can
close the form containing the report. When I close the main application I
get the errors.
Any ideas of where I can start troubleshooting. Also is there a preferred
method for opening the datasource for the report. This report program first
creates a data extract table, then should execute the report. So I open the
table, then the pipeline after the extract table is created, but prior to
running the report. Afterwards, I close the pipeline, then the table after
the report executes.
Thank you very much,
Mike Malinowski
This discussion has been closed.
Comments
Since I first posted, I have tried to isolate the problem. I now have only
a ppReport component on the form. The report contains 1 text label in the
page header. At runtime, I load the report template, and do a
ppReport1.Print. It displays the preview of the report. I close the
preview window, then the form, finally when I close the application I
receive an Access Violation. I no longer have a table or datasource or data
pipeline on the form. Just the report object.
This form is part of an application we've developed and distributed for
years. We are interested in implementing ReportBuilder as the reporting
tool. We purchased ReportBuilder and I've been attempting to integrate
since last week. Any ideas as to what may be causing something like this?
Thanks,
Mike
first, when you load templates at runtime use a blank report.
Do you receive any AV when not calling a report action?
What happens when you replace 'ppReport1' with a new component?
Are you freeing any components by code?
Is the AV raised when you execute the application outside the IDE?
regards,
Chris Ueberall;
To further clarify, the RB Report object is on a form which is not part of
an EXE. It is part of a DLL. Our application is segregated into DLLs.
We've stepped through this, and it appears the problem (Access violation)
occurs after the report has been previewed on the screen, and not when sent
directly to the printer. It appears that the preview form is not being
freed by the ppReport. I am not doing anything other than calling the
default Print method after the template has been loaded.
Thanks,
Mike
Yes, the error is raised outside the debugger. I am not explicitly freeing
anything. Only because I have not programmatically created anything.
Please see the additional post regarding the fact that this form is part of
a DLL.
Thanks,
Mike
you get the same runtime error running the demo reports? If so, it is
possible that you might have a corrupt install of RB. In that case, please
follow the guideline below for reinstalling RB. If the problem persists,
send the sample project that reproduces the problem to
support@digital-metaphors.com.
The TppDBPipeline has an OpenDataSource property which, when set to true,
will attempt to open the data source before traversing the report.
----------------------------------------------------------------------------
------------------
Run the uninstall program
1. Exit Delphi, and all other applications. You should have no applications
running except the uninstall, otherwise you may lose some of your work.
2. Select Start | Settings | Control Panel from your Windows desktop.
3. Double-click the Add/Remove programs icon.
4. Locate the version of ReportBuilder you wish uninstall and double-click
it.
5. The first page of the Uninstall Wizard allows you to choose between an
Automatic or Custom uninstall. Choose Custom and click the Next button.
6. Click the Select All button, then the Next button. Repeat these steps
until you reach the last page of the wizard.
7. Click the Finish button. All of the items you selected will be removed
from the system.
8. After all the ReportBuilder files are removed, you may be prompted to
reboot the system. If this is the case, reboot the system.
Delete the ReportBuilder root directory (and all subdirectories)
1. Using the Windows Explorer, locate the ReportBuilder root directory. The
default directory is:
C:\Program Files\Borland\DelphiX\RBuilder
2. Once you have located this directory, inspect it. If you have any custom
work in this directory which you would like to keep, move it to another
directory.
3. Delete the ReportBuilder root directory.
Delete all remaining ReportBuilder files
1. Using the Windows Explorer, search the entire hard drive for all
occurrences of:
dclRB*.bpl
dclRB*.dcp
rb*.bpl
rb*.dcp
2. Delete any occurrences which correspond to the version you are removing.
All packages are named with the convention NN, where the first number
is the ReportBuilder version and the second number is the Delphi version.
Thus, a typical package name for Delphi 5 would be rbRCL45.bpl. The same
package for Delphi 4 would be: rbRCL44.bpl. Check Installing ReportBuilder
for a list of the packages associated with each version.
3. Using the Windows Explorer, search your hard drive for all occurrences
of:
pp*.*
da*.*
ra*.*
4. These are the prefixes used by individual ReportBuilder units. 'pp' is
used for ReportBuilder units, 'da' is used for DADE units, and 'ra' is used
for RAP units. Depending on which ReportBuilder you have (Standard,
Professional or Enterprise) you may not have all of these unit types.
Additional Notes
1. Never have Delphi running when installing ReportBuilder.
2. All ReportBuilder related files should be stored in the root directory
$(DELPHI)\RBuilder.
3. All ReportBuilder run-time packages should be stored in the
Windows\System directory.
4. You should never have ReportBuilder files in Delphi\Lib, Delphi\Bin or
Delphi\Projects\Bpl.
--
Cheers,
Alexander Kramnik
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com
Demos do work. I've set up a couple of simple applications just to try
different ReportBuilder methods. As a matter of fact, I was able to design,
and run the desired report from a standalone EXE. To the screen, printer
and export.
It wasn't until I attempted to integrate the same report into our actual
application. That's when we concluded that it worked in an EXE but not a
DLL, which is how our application is structured. If the report is printed
directly to a printer, there is no access violation on closing the
application. But if the report is previewed to the screen, we receive the
access violation. Stepping through the code of ppReport, and ppProducer it
seems the default preview form remains unfreed.
Thank you,
Mike Malinowski
"Alexander Kramnik (Digital Metaphors)" wrote
Assuming that the preview form isn't freed doesn't harm anything. You'll
have a memory leak if more than one preview form is created without freeing
them - but no AV.
You better go with BPLs rather than DLLs.
regards,
Chris Ueberall;
Chris,
For whatever reason, I am experiencing Access violations and runtime errors.
They occur only after a Print to the screen. It does appear that the default
FPreviewForm is nil after ProcessMessages is called in
TppProducer.PrintToScreen
What I did discover was, that if I set ppReport1.ModalPreview to False then
FPreviewForm.Show is called instead of FPreviewForm.ShowModal and the
program shuts down cleanly.
As far as the BPL vs DLL issue, our program is quite extensive and has been
in distribution for several years with DLLs, and has worked quite well. I
have yet to discover why ShowModal makes a difference, but I can at least
continue to test the report component within our application. We would still
like to use ReportBuilder to replace our current reporting tool. I hadn't
run into any major snags using ReportBuilder until this happened.
Thank you for your help. If you think of anything else please pass it along.
M Malinowski
RB can work in a DLL. We recommend using packages, but if you have to use
DLLs, then follow the demo's approach.
Cheers,
Jim Bennett
Digital Metaphors
http://www.digital-metaphors.com
info@digital-metaphors.com