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

Mysterious range error

edited February 2003 in General
A report that has been working in production for 6 months. Added a new
field to the TADOquery. Deleted all the field definitions in the
TADOquery and then added all.

Added the field to the report. Run the report. Get a range error
(overflow) on a field. For a different selection criteria, get a range
error on a different field. The range error happens when the report
itself is called.

Put exceptions around the couple of events with custom code called by
the report. They don't fire.

Deleted the data pipeline and added it back. Double-clicked it so it
could add the fields.

Added a grid so I could see the data. The largest number is 33. The
field is a TBCDField with a precision of 16 and size of 0.

Still getting a range error. I don't see how or why. With one set of
selection criteria, I can get the first page of the report to show up in
the preview, but the second page bombs with the range error.

Where do you think I should look next?

Comments

  • edited February 2003

    If the TField.FieldType is ftFMTBcd, then RB internally converts the type to
    Double.

    As a test try the following:

    1. Modify your Delphi library path from RBuilder\Lib to RBuilder\Source

    2. Add a TButton to a form and add the following code to the OnClick
    event-handler:

    var
    ldValue: Double;

    myPipeline.Open;

    while not myPipeline.EOF do
    try
    ldValue := myPipeline.GetFieldValue('myFieldName');

    if (ldValue > 10000) then
    ShowMessage('The code is to fool the optimizer');

    myPipeline.Next;

    except
    ShowMessage('Exception!!!');

    end;


    --
    Nard Moseley
    Digital Metaphors
    http://www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2003
    The test flips through all the records without error, but the report
    still has the exception. I'm tracing through the
    GetFieldValue(dataField) in function TppDBText.GetFieldValue: Variant;
    in ppCTrls right now.

  • edited February 2003
    I *think* -maybe- I've pinned down two actual bugs in rb:

    1) Based on where the debugger indicates a problem in the source: when
    there's an exception in getfieldvalue, somehow the wrong field is
    reported. The exception here looks like it's happening in the
    getfieldtype. However, none of this ties in with what is really
    happening. What was really happening is that one field that is set on
    the groupfooterband beforegenerate event, and that field cannot hold the
    data, hence the overflow. But it's the not the field that's coming up
    in the exception! The field that's showing in the exception is the
    immediately previous field.

    2) when you add a new pipeline to an open ado query, there's an apparent
    bug in how the pipeline fields get created for TBCDField's. For a
    TBCDField, according to the Borland help file and observation, the size
    of the field is in the PRECISION property, and the number of decimals
    are in the SIZE property. But the pipeline creates a TppField with a
    size = size of the TBCDField, which is much smaller than the TBCDField
    as a whole.
  • edited February 2003
    Scratch #2 - it makes no difference what the TppField size is.



  • edited February 2003
    This one field will not allow the assignment of any decimal places,
    period. If I round the data before assigning in the beforegenerate
    event, no problem.

    I can't seem to find any differences between the form variable in RB on
    the report design screen and others very similar that don't have the
    problem, nor between the TppVariable in the pipeline and others very
    similar that don't have the problem, nor between the ado query field
    and others very similar that don't have the problem.
  • edited February 2003
    Now that's not working either (rounding) - it was working a few minutes ago.

    There's something very weird and unstable happening and I think it's
    with the pipeline. I got an AV when I clicked on it, so I closed the
    project and reopened, and all my workarounds no longer work. So I'll
    try deleting the pipeline and adding it back again.

    Needless to say, this has been a very tedious trial-and-error process of
    trying to figure out what is happening in the "black-box". Shows the
    limits of "having source" - if you don't know the product intimately,
    tracing is just a maze and has not gotten me anywhere so far.

    I can't wait for this to go pop and be over...



  • edited February 2003
    Okay, here's the solution:

    1 set all the components on the report with a pipeline property to
    parentpipeline.

    2 delete the pipeline.

    3 Delete all the fields from the TADOQuery, and set it inactive.

    4 Change the TADOQuery's ENABLEBCD property on the TADOQuery to false.
    Set the TADOQuery active. Open the fields editor and add all the fields
    back. Now you will not nave any TBCDField - you will now have TFloatFields.

    5 Add the pipeline back on the form and name it what it was named
    before. Double-click it and it will come up with all the fields newly
    created. Close it.

    6 Select the report and set the pipeline property to the pipeline you
    just added back. Save it.

    This fixes everything. Looks like RB doesn't "like" BCDFields, (at
    least for assigning new values in groupheaderevents).

    Thanks for the suggestions - those put me on the path to finding the
    problem.
  • edited February 2003

    Good to hear that found a solution.

    E-mail support@digital-metaphors.com with steps on how we can recreate this
    issue and we'll check it out.

    --
    Nard Moseley
    Digital Metaphors
    http://www.digital-metaphors.com

    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • edited February 2003
    Thanks for the pipeline field iteration idea. That's a good technique to
    debug external to the reporting events, where it's much easieer.
This discussion has been closed.