Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

Error

edited April 2002 in General
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

Comments

  • edited April 2002
    Hi again,

    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


  • edited April 2002
    Hi 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;

  • edited April 2002
    Hello again,

    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

  • edited April 2002
    Chris,

    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

  • edited April 2002
    Please try to run one of the ReportBuilder demos found in RBuilder/Demos. Do
    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

  • edited April 2002
    Alexander,

    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
  • edited April 2002
    Mike,


    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;
  • edited April 2002

    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

  • edited April 2002
    There is a DLL example in the installed RBuilder\Demos\DLL which shows how
    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

This discussion has been closed.