Hi Colin, Yes it has been a while. It's also been a while since our countries have battled it out on a sporting field or something else, and I am sorry to say that in Australia we do not hear a lot of news about New Zealand unless it involves us, or we can somewhere try to take credit for it, so we tend to forget about our almost sibling neighbour.
Back to DP. If I get your drift you want to process the calculations in an overall context by iterating through all or a group of record and then using data obtained from this iteration go back and have the report loop through the required records to calculate and/or output them to a report. I think you might be able to use a technique I employed with the DP web based reports. Firstly, I have made it a habit to include a panel in every DP database that has just one record, no more no less, by having an index of a field which has an initial formula with a constant result. Often I would use this panel, for notes about the application, or for licensing details, or other system wide data. Every report I write is based on that panel, and real reports are only ever handled as subreports on virtual links from this dummy panel record. The subreports areeither restricted by a variable (usually in my case coming from the user.field[0] with the /SID start up parameter value for web work) but sometimes without any filtering. With the dummy pane and single record you are guaranteed to be able to run a report whether there are records or not in the panel you really want to work with. After finishing that subreport, or for it branch off to run a different subreport(s), you can add more reports, related or unrelated. It was a way of chaining multiple reports together. IF DP development had continued I would have requested that you could use different actual DP reports as subreports to make for modularity and code reuse. In the case of a web form the first subreport would loop through table of web field/value pairs and SID values imported, restricting the visibility to only those records in the panel matching the SID value, and then I would save these values to DP variables, for use in the next report. I mention this not because you have to do this, but just to show you the context of what I am suggesting. After this first subreport, I'd create another virtual subreport, where I can take actions, such a retrieving data from records matching say a search field, or for deleting records, adding or editing data etc, often in multiple tables. As a web database it was far easier than using SQL statements in some middleware, DP was both the data repository and reports were my middleware processing So In your case I would do something like this. >>>>>>>>>>>>>>> based on dummy panel with one record Report Header FirstpageHeader Report Body Reset variables if required SubReport >>>>based on Panel 1, and including subreports on panel 2, and panel 3 etc to get what you want in aggregate Subreport End SubReport >>>> do stuff that you prepared for in the previous subreport, using data variable etc SubReport End Page Footer Last Page Footer Report Footer <<<<<<<<<<<<<<<<<<<< end of report I had one report which managed a complex import of data from an uploaded file, where there were user defined fieldnames in the import file which I had no control over, that the user could map to fields I could capture for populate records in DP panel(s). The report was massive, and had loads of subreports, I think somewhere around 50 subreports, so much I was worried about DP's 64k limit on a report specification. But it was very powerful, in fact almost all types of procedural processing looping; for-next, do while, do until, counting etc, that you would be able to do with a procedural based programming language can be simulated in DP. Frequently I have had one loop calculating the value for a variable that would be used in a counter for another loop, incrementing or decrementing it in a subreport until an end report on Skip to record and a false(0) to stop it. Reports with so many subreports can get quite complex, so there was more structural planning and I always reserved a variable which I would store comments in about the SubReport or anything complex I was doing. E.g., RV1 = /*this is my comment about the processing about to happen or flagging the end of a process */0 I also kept notes about the structure of each report, usually in a memo field in records in another panel. Another technique I often used was create a Panel with two fields, a RecordNumber field and a reportID field. So during the preprocessing of records (almost all my panel use a recursive link to create a consecutive number as the Primary Key), I could store off the RecordID + ReportID of records I later wanted to include in the next phase of the report, and then use panel as the receptacle of other subreports linked to these record numbers. At the end of the real reports back in the dummy panel report body I would use one last subreport, to loop through my temporary panel data linked by my reportID and delete it all to clean up after the report. One of the major complexities in DP web work is that everything has to come into and out of the database via T-Logs and subsequent reports, and that you never know how many simultaneous users are going to be running reports, so much of the complexity was to make sure that no two peoples' inputs could interfere with another's. I do know at the peak of one of my applications that it once had 40 simultaneous web reports running concurrently each only executing for about 5 seconds, which would have equated to just under 30,000 report execution/transactions per hour. I have one application which has now been running at a commercial web hoster under Linux and DOSEMU, that I write in 2006 which is still going, albeit with far less usage than it used to, but I just never have to touch it, and have not once had to answer a support question about it, so these complex reports can be very robust. Good luck Brian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Colin Roberts Sent: Wednesday, 30 July 2014 12:17 PM To: DataPerfect Users Discussion Group Subject: [Dataperf] DataPerfect Report - Is this do-able Hi All, Been a while :-) Wanting to modify one of my existing reports to produce a seperate "cutting list" at the end of it. Basically have 3 x user data entry panels 1. Order Entry Panel, 2. Door Calculation Panel, and 3. Door Prehung Calculation Panel Panel 2 is child of panel 1 and Panel 3 is child of Panel 2. Currently Report is single level report based on Panel 1, with subreports within Report body to show required data from Panel 2 and Panel 3. All is fine and this report, with on-going modifications, has worked fine for years. Recently discovered supervisor in Factory has been manually producing a cutting list for Door Frame jambs which is coming from the subreport/data connected to Panel 3. He writes the data down manually in a slightly different format with a couple of re-calculations. Dataperfect can easily produce that data in his format within the subreport. But..... What I would like to do is calcualte the cutting list as each item is processed within the report but hold it over so that a seperate list is printed at the end of the report containing all the required data relating to Panel 3. Appreciate its easily achieved by running a separate report that processes just the required data but that does rely on remembering to print it. If the data required is stored in a report variable for each item I can see no way of printing each items data, line by line, in the final footer or at the end of the report (Preferably on a new page). So I'm looking at maybe Two level reports, parallel reports or, if possible, a report within a report - so all the info required is produced running just a single report only once. Thought I'd draw on this wonderful resource to see if what I want to do is do-able before I spend too many hours reading through Ralph's Book and trying to figure out best approach. Hope the above makes some sense - any pointers would be much appreciated Regards Colin Roberts _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf _______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
