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

List Index out of Bounds

edited February 2012 in General
Hi

I am in the process of updating one of my customer's applications (Delphi
2007) from RBEnt 12.3 to 14.3 and am experiencing strange behaviour when
previewing a report.

There are two datasets sqlSorder and sqlSoitem displayed in a master detail
relationship. Each of these datasets has a TDataSource but only the
sqlSorder has a TDBPipeline. Because i need a slightly modified set of data
i am using a third dataset sqlSoitem2 with a TDataSource and TDBPipeline for
reporting purposes. SqlSoitem2 is only used for reporting purposes and is
not bound to any data controls. SqlSoitem is bound to a TwwDBGrid
(InfoPower).

As SqlSoitem is not linked to any pipeline i have historically not bothered
to use DisableControls prior to printing. However after updating to RB14 i
have found that unless i do this i have been getting List Index out of
Bounds and NTDDL access violations with a blank TwwDBGrid (although
strangely the grid still seems to be working if invisible) when i preview a
report on screen. The report itself seems to work fine and when i preview
the report again it displays fine with no error messages. However my grid
is unusable and i have to close the form to rectify the problem. The
problem appears to be solely when previewing the report. Sending direct to
a printer or printing to PDF does not appear to have any problem. If i do
sqlSoitem.DisableControls prior to preview then i do not appear to have any
problem.

I had already noted from another application i have upgraded that it now
seems essential rather than just good practice to DisableControls. Does
anyone know why it is now critical and why i should have to disablecontrols
on a dataset that is not even connected to a DBPipeline? That seems very
odd to me.

Regards

Tim Murfitt

Comments

  • edited February 2012

    Could it be because sqlSoitem (which is not connected to TDBPipeline)
    has master dataset set to sqlSorder (which is cinnected to
    TDBPipeline)?



    On Tue, 7 Feb 2012 18:46:10 -0000, "Tim Murfitt"
  • edited February 2012
    Zoran

    Thanks for your input. You may be right but i am not sure that is the
    problem.

    sqlSoitem.MasterSource is nil but sqlSoitem.DataSource = dsSoall (required
    to link parameters of sql to the sqlSoall data) so i suppose there is a
    connection to a DBPipeline. To test the issue i changed the way i ran the
    sqlSoitem query. In doing so i found that the sqlSoall.AfterScroll event
    fired multiple times (5+) whilst the report ran even though the pipeSoall
    pipeline is set to current record. I dont know if this should be happening
    but i was surprised to see it.

    By Disabling Controls the problem goes away but something has definitely
    changed between v12 and v14. Hopefully someone at DM can shed some light
    (particularly why it is only a problem with Preview) and give some guidance.

    Regards

    Tim




  • edited February 2012
    Look like SinglePageOnly property sets to false.
    This is new functionality of RB 14.

  • edited February 2012
    Dima

    You are correct. Changing PreviewFormSettings.SinglePageOnly to True
    removes the necessity of Disabling Controls so that is clearly what is
    causing the issue and explains why there is only a problem when previewing.
    I do however like the new scrolling facility and would be reluctant to
    disable it. It would be nice to know if everything is working as DM
    intended or if there is still something going wrong. Just because i did not
    DisableControls i would not expect to get all the errors and access
    violations i was encountering.

    Regards

    Tim


  • edited February 2012
    Hi Tim,

    Setting the SinglePageOnly property to True simply reverts back to the
    older RB 12 and prior Viewer/Screen Device (one page at a time).

    For RB 14, the Screen Device was completely redesigned to handle
    processing and viewing multiple pages at once. This was an extremely
    large change to the way ReportBuilder functioned in the past.

    In order to allow quick viewing of a report with multi-page capability,
    we decided to generate all pages in a background thread while still
    allowing the user to view the report as this is happening. It is during
    this time that it is sometimes necessary to disable all DB controls so
    the thread can finish it's job uninterrupted.

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited February 2012
    Nico

    Thanks for your response. Can you please give some guidance on what is the
    best policy if i am going to view multiple pages. Should i disable all data
    controls prior to preview?

    Regards

    Tim



  • edited February 2012

    Couldn't you disable/enable controls in the process of generating
    pages, instead of us doing it manually?



    On Wed, 08 Feb 2012 07:36:07 -0700, "Nico Cizik (Digital Metaphors)"
  • edited February 2012
    That's not possible in general.
    Data (DataSources) can be very complex, have a lot of relations.
    And Report cannot know about all of them.
    Additionally - what about JITPipelines that can be connected to DataSet
    but used instead DBPipelines for some reason?

    You have to do this manually.

  • edited February 2012
    Hi Tim,

    The DisableControls property essentially prevents data-aware controls
    from updating every time the active record changes. If you are using
    datasets for your report(s) that were created to handle other aspects of
    your application, it is necessary to set the DisableControls property
    before printing/viewing the report.

    Having dedicated datasets for report use only is another option to
    prevent the issue.

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited February 2012
    Nico

    It seems to me that with multi page previewing in RB14 it is ESSENTIAL that
    DisableControls is set for datasets (If not there are likely to be errors
    and AVs). With single page previewing DisableControls is recommended but
    not essential (no errors but slow because of updating).

    I had already used a dedicated dataset for the detail data (as in Master -
    Detail) but still got errors. It was not until i had DisabledControls in
    the dataset not connected to a pipeline that my problem was fixed. Maybe if
    i had done a DisableControls on the Master dataset then i would not have had
    a problem but i dont know. Historically i have never bothered to
    DisableControls when the pipeline is set to the current record or there is
    only one record in the dataset. Maybe that policy has got to change.

    I appreciate that this is a big alteration to how RB works and one that i
    like but i think that there are still some glitches to be fixed.

    All the best.

    Regards

    Tim



This discussion has been closed.