Razzak, I will take a look at your suggestions, although I do use DB Calc often, especially in more recent apps. This particular app was developed in the days of 6.5, and yes, the reports are probably a little out of date from a programmatic point of view. Sort of the old "if it ain't broke, don't fix it". Already have an update to the report in mind, easy!
Thanks, Steve BlackBerry Z30 Original Message From: A. Razzak Memon Sent: Thursday, October 5, 2017 7:18 AM To: rbase-l@googlegroups.com Reply To: rbase-l@googlegroups.com Subject: RE: [RBASE-L] - Report Question Steve, Without knowing all details and everything else on your end, did you look at the sample "SubTotalsAndTotals" report included with RRBYW19 database to understand the use of both techniques? Also, you may consider using the "DB Calc" to calculate sub-totals, totals, etc., as demonstrated in the SubTotalsAndTotals report. Hope that helps to show you the difference to make the right choice. Very Best R:egards, Razzak At 12:52 AM 10/5/2017, Steve Johnson wrote: >Razzak, > >Thanks. As suggested, the variables involved were already declared >and set to null or 0 within the eep in the menu item. As an >experiment, I also declared them in the report "before generate" and >the problem still occurred. Changing the cache setting did the >trick, even with the declared variables removed in the "before >generate". However, the cache setting was originally on (I >presume-dark appearance), turning it off (light appearance) caused >it to work correctly, which suggests the opposite effect of the >cache setting suggested. I used the trace routine for the menu code >and could see the effects on the watch variables, with or without >cache setting turned on/off with same results. > >So what is happening? When the report is printed to screen, I >presume the variable content as the result of the calculation within >the report is retained until the report is either closed or the >variables cleared within code. When the report is actually printed >to a printer using the print options in the screen version, it >suggests the report is re-generated and depending on the cache >setting, the original variable content is either retained and >therefore doubled (in my case), or the variable involved is cleared >(because the report is not cached) and the result is >correct. Assuming my explanation is correct, is this behavior >limited to only calculated variables within a report detail band or >all bands? Is there a general rule of thumb in the use of cached >pages? My staff likes the forced print preview where they can choose >how to print the printed report (printer, pdf, or even the number of >pages) from the screen report if all is ok and the code to do it is simple. > >Steve J > > > >-----Original Message----- >From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On >Behalf Of A. Razzak Memon >Sent: Wednesday, October 04, 2017 1:14 AM >To: rbase-l@googlegroups.com >Subject: Re: [RBASE-L] - Report Question > >Steve, > >Here's how ... > >01. When working with variables (sub-totals and totals), the best >approach is to ALWAYS initialize all variables to NULL or 0, as >report "Before Generate EEP". > > Report Designer > Main Menu > Report > Actions > Before Generate > -- Example > SET VAR vTot1 CURRENCY = 0.00 > RETURN > > This will always start the variable as 0.00 before the actual > report is generated. > >02. Make sure to check the option for "Cache Pages". > > Report Designer > Main Menu > Report > [x] Cache Pages > >That's all there is to it! > >You may take a look at the sample report "SubTotalsAndTotals" >included with RRBYW19 database to understand the use of both techniques. > >Hope that helps! > >Very Best R:egards, > >Razzak > > >At 12:57 AM 10/4/2017, Steve Johnson wrote: > > >I have a very simple report that prints out a list of checks with their > >corresponding totals. The check amounts are totaled with the result > >stored in a variable and that variable is subtracted from another > >variable to arrive at a balance. When the report is printed to screen, > >the results are correct. But when the same report is printed to a > >printer using the print options in the screen version, the check total > >amount is doubled. This has worked literally for years, but at some > >point, this error started. I am using XE. > > > >This is the print code in an eep, where the screen total is correct but > >which results in a doubling of the check total when the report is > >printed from the screen: > >PRINT ledger1 ORDER BY checno OPTION SCREEN|WINDOW_STATE MAXIMIZED > > > >If I substitute the following in the same eep, ie., printing directly > >to the printer, the results are correct: > >OUTPUT printer > >PRINT ledger1 ORDER BY checno > >OUT scrn > >The variable in the report is: 1 : CURRENCY : D : VTOT1 = SUM OF > >CHECTOT So the question is what is happening between printing to screen > >(essentially a print preview) and then printing to printer from the > >screen that is causing a doubling VTOT1? The OPTION SCREEN provides > >the printer icon in the toolbar that essentially provides for many > >print options. It is a convenient print option from a report generated > >to screen as a preview. > >-- >For group guidelines, visit >http://www.rbase.com/support/usersgroup_guidelines.php >--- >You received this message because you are subscribed to the Google >Groups "RBASE-L" group. >To unsubscribe from this group and stop receiving emails from it, >send an email to rbase-l+unsubscr...@googlegroups.com. >For more options, visit https://groups.google.com/d/optout. > >-- >For group guidelines, visit >http://www.rbase.com/support/usersgroup_guidelines.php >--- >You received this message because you are subscribed to the Google >Groups "RBASE-L" group. >To unsubscribe from this group and stop receiving emails from it, >send an email to rbase-l+unsubscr...@googlegroups.com. >For more options, visit https://groups.google.com/d/optout. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to rbase-l+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to rbase-l+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
