Joe, By saying " 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." You have simply confirmed that the input into the report needs to be generated independent of the report itself, hence approaching the problem by creating a single input cursor.
In all my years of VFP work I have never had to deviate from this philosophy and believe me, we have created some majorly complicated reports! For the times when the format of the report required either colored text etc I have used the ReportListener feature to allow dynamic formatting and you can actually modify the report contents/structure in real time using RL's if you so desire. On a couple of occasions I have actually created the report in line by opening up the report as a table and modified the contents but always using the principle of having a single cursor as input. Best of luck! Dave -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of Joe Yoder Sent: 02 July 2015 03:13 To: Foxpro forum Subject: Re: Outputting the contents of cursors in a Report Summary 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/[email protected] ** 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.
