Danger of using a shared variable from a detail level subreport?

[Former Member]

Ok, here's the situation.  I'm building a custom report for a PO based on a stock Syteline sp.  One extra piece of information I need is a UDF at the PoLineItem (POLI) level that holds a conversion factor for qty and unit price calculations.  I have a subreport that is retrieving the POLI notes from a SL stock view and passing them to the main report via a shared variable.  I have placed the subreport in the Detail A band and it's properly suppressed so it executes fine but is hidden.  My main detail band is Detail B.  The notes are actually used in Details D.  (Details C is vendor item info provided by the main sp).  I have the subreport wired to the main report via a POLI row pointer provided in the stock sp result set. 

In the sp for the subreport that gathers the notes, I'm also grabbing the UDF I need as well and again passing it along via a shared variable.  Some concern has been expressed that this may not be a solid approach and could result in incorrect conversion factors being applied to PO lines because of the order the subreport and calculations are performed or rendered. 

In other words, the conversion factor for line 1 may be applied to line 2 and therefore cause an order of 5,000 to slip out for a part that we typically order 50 of.

So I'm looking for some input as to a different solution, some way to assure that the correct data will always be provided for the line, say by forcing the execution of the subreport at a specific time, clearing the variable after each line, etc. or anything anyone else can throw at me.

I thought I could perhaps use one of the evaluation time functions but that doesn't appear to fit my situation either.

If I didn't explain myself well enough, please ask for a specific explanation about the confusing part and I'll do my best to give a better example \ answer.

Thanks

[Former Member]

Hi Adam,

I am a bit confused on the order of subreport and shared variable that you placed in the main report.

Anyways, you can create a new formula to reset the sharedvariable value to zero, something like this.

Asuming your shared variable to be x, create the below formula:

Whileprintingrecords;

Shared numbervar x:=0;

Place this formula in the section next to which you want to reset the shared variable.

Thanks,

Kiran

[Former Member]

Hi Kiran, I'm not sure whats confusing, I guess to simply, if you're looking at the report from top down it'd be the subreport that contains the detail information I need, the main detail band with fields from the main report and formulas containing the subreport info.  Those are all that really matter. 

My understanding is that CR doesn't necessarily evaluate in a "top down", iterative fashion?  Maybe I'm wrong? 

Are you suggesting I put the reset code you mentioned above in a detail band after the detail band that uses the subreport info?  That sounds like it would work if the report is evaluated iteratively...

[abhilash_kumar]

CR indeed evaluates in a top-down manner (and usually top-down left-right).

A Subreport that brings back records for the Main Report using shared variables will always need to execute before that value can be displayed in the Main Report.

-Abhilash

[Former Member]

Ok, that being said, executing the sub report in Details A, utilizing the shared variable in Details B, and setting the shared variable to 0 in Details C, should produce consistent results for any number of lines on my PO then.  Correct?

[Former Member]

Yes it will