I was assuming there would be a way to create the array in the report environment which should eliminate any scope issues. I haven't tried doing it in the environment from which the report is called but I will.
By way of explanation - I would prefer to use the cursor directly as I could set up one line of fields to display a record from the cursor. I could replicate the fields in that line, position them, and be finished provided there was a way to have the cursor record pointer increment between lines in the report. With the array approach I will need to specifically specify the array element for each of 60 - 80 fields but won't need to move any record pointers. I have not worked with report generated variables. If the report can name the variables based on the distinct data it finds in each of the three fields I need to summarize by and accumulate the amounts for each breakdown as the detail is processed - that should give me the data that I need. I already have the data in the three cursors but am flailing around trying to figure out how to display them. If having the report generate the variables inherently gives me the ability to display them I will want to investigate further. I should mention as well that this system needs to stay data driven. As additional functions are added to the system there will be new Account Types showing up in the data. If I hard code names I will need to come back again and again to update the code. Joe On Wed, Jul 1, 2015 at 8:25 PM, Ken Dibble <[email protected]> wrote: > > Is there a way to read the cursors into arrays when the form initializes? >> > > SELECT * FROM MyCursor INTO ARRAY aMyArray > > Autocreates the array if it doesn't exist. But you can reference as many > different distinct data sources as you have fields in the report, as long > as they are in scope, so I don't see why you would prefer arrays to cursors > in that case. > > If you want the execution of the report itself to generate the summary > data then the report variables are the way to go. > > Though I agree with the people who say: Denormalize and process everything > down to one or more cursors, perhaps, say, one cursor per detail band, and > one cursor for header and summary data, before running the report. It's a > lot easier to understand, and it has the advantage of being portable in > case you need the same or similar data in a radically different report > layout. > > Ken Dibble > www.stic-cil.org > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CABQeDnUVf=hknfpx1rfn6w673fd1uz40k0cdqegvzkrt9mz...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
