List Index out of Bounds

rbuser

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

rbuser

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"

rbuser

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

rbuser

Look like SinglePageOnly property sets to false.
This is new functionality of RB 14.

rbuser

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

nicocizik

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.

rbuser

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

rbuser

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)"

rbuser

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.

nicocizik

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.

rbuser

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