well, I guess one would have to ask how did the array get filled in the
first place. No doubt the data came form a table. Since that is the case,
perhaps then in place of using a array, you can use a query, and some custom
built functions?
I do actually have a good number of reports where there is TONS OF code for
data processing. The trick is to build a query that returns at
least the record id's in order for the report to process on. Often, the
query might even only return a list of end dates, and the report code
can run from that list. Often, I also load up a reocrdset with
the same info at the forms load time. You then can use the on-format event
to run code and process data for EACH record in the report. The results of
the processing can thus be put into un-bound text boxes in the detail
section of your report. So, for example, you could keep your array, and
then process each element via a query that returns some "id" in the array
(or some date, or whatever). However, I often find that a collection is a
FAR better structure to use then is an array. Collections are not updatable,
but they certainly are better then a array because you can use a key
id for each element. With an array, you can't really work the data out
of order (you also have to "scan" the array for id matches). All in all,
an array is a VERY poor choice of a data structure. While in the old
days, arrays seemed like a very useful data structure, they really
are out of place in modern development systems. 99% of the time, you have
much better alternative then using an array.
..
Unfortunately, reports need to process the data more then once (forming
time, and hen printing time).
So, really, your best bet is to dump the array, since it probably got its
data from a table anyway. Change your processing model to process the data
from a query, and not an array. However, if you must keep the array, you can
usually feed the report a list of "id"s from a table, and then simply write
code and functions that work off the id. Of course, there is also the
possibility
of writing the data out to a temp table (but, that should be advised at all
costs, as we all know that temp data tables are about the WORST thing you
can use in ms-access, and they cause bloat in the application.
It would very hard to imagine that the array data did not at least in some
part come from a table.
I have a number of reports that are cross tab,and thus the headings, and
even the detail data boxes are un-bound, and the data does come from a
recordset. Without question, the reocrdset could have been a array, but
searching the array would have been a pain. However, my only point is
that the data in the report matrix is done via my code, and *mostly*
un-bound text boxes. However, some record list was generated for the
report to "work on".
