I have a .fex that 'drills down' into itself on many different levels.

For example, It drills for a
Region
to a Divisions within the Region
to Stores within a division and
Stores within the Region.

Is there any way to store an amper variable globally, so that it doesn't necessarily need to be passed from one level to the next, just set it as global and reference it later within my code?

Thanks!

Each report request is an individual WF session, therefore global variables will not be available from one session to another. The only ways I can think of to pass parameters between sessions (without passing them in the actual request) would be to create a cookie containing the parameters and values or writing the parameters and values to a file.

Thanks francis, that makes things a little clearer now.

How does the !IBI.AMP.MYVARIABLE; work?
Where does the information for 'myvariable' reside when I use this method?

&MYVARIABLE would be one of the four following types of Dialogue Manager variables:

- a parameter passed to the fex by a form or a calling fex (EX or -INCLUDE)
- a parameter created withing the fex itself
- a 'system variable' parameter, eg. date: &YYMD
- a 'system variable' parameter passed to the fex via settings in a configuration file, eg. site.wfs or cgivars.wfs in c:\ibi\srv53\wfs\etc\

Francis you forget the ones you can create by / in edasprof.prf .

Frank, I could be wrong, but, as far as I know, you can only create global variables in edasprof.prf, which are

&&MYVARIABLE - !IBI.GLB.MYVARIABLE;

I'm still struggling with this...
is it common to drill down three levels in the same fex, where the third level can acquire data from the first level?

For example, From
Region to Division - pass region From
Division to Area - pass division and/or Region
Area to Store - pass region, division, area...where any of these could be FOC_NONE.

Such a confusing thing we're trying to do. Logically it makes sense, but when I'm trying to code it in webfocus I would like to store the Division that they drill into as a permanent value for the session they are using, that way when they get to the store level, the division session variable can be gathered and used in the where clause.

Ideas?

Jason,

I always think that the safest method is to force the control within your code and to pass these values in the drilldown style code.

And no, it is not unusual to drill down many times from one report to another. However, if the data level and quantity is not too large then using EXPANDABLE might be a suitable alternative, as there would only have to be one pass of the data and therefore your end user would benefit from the reduced time of retrieval at each drill down.

T

Thank you for the reply Tony A.

Could you clear this up for a newbie?

quote:

force the control within your code

The rest of your suggestions make sense...1) use an accordian report. 2) it's acceptable to pass data between different fexes.

If this were different fexes, things would be simpler I think. I could simply add a MAX.STORE NOPRINT and just pass it on, the problem is that we have only one fex, 4 options for region/division because divisions can span regions and regions can span multiple divisions, and 8 options for viewing data from customer, to product line to sales acccount codes...again, all of these options seem to span over each other in such a way that there is no heirarchy to speak of.

I'm sorry if I didn't make that clear when I originally posted this.

You can pass an amper-variable between fexes in drilldowns. It doesn't have to be a field on the report itself. That way you can preserve all the selections that were chosen by the user. I think that is what Tony meant.

The default setting for WebFOCUS is that &&global variables are saved in a browser cookie. So they will continue to live as long as your browser is open.
It is not always the correct solution to the issue --- but it is available. (Note: This facility can be turned off in the admin console --- IBIF_persistentamp ).

Jason,

N.Selph understood what I meant, sorry, but I didn't mean to it be hard to follow.

As Brian says, what used to be "global" variables are now dealt with by using cookies to hold the values. Howvever, as Brian intimates it is not always safe to use these. That is why I always prefer to force the values through on the drilldown column -

TYPE=DATA, FOCEXEC=yourfex.fex(Variable1=&Variable1 Variable2=&Variable2 ....), $

Just because you're passing variable and their values doesn't meant to say that you have to use them (although why you would do this etc. etc.)

T

Don't forget, you need to use quotes around alpha variable values:

TYPE=DATA, FOCEXEC=yourfex.fex(Variable1=&Variable1 Variable2='&Variable2' ....), $

i think the && variable is what I'm looking for.

You fellas are GREAT!

Buy us a pint?

I agree with Tony A. Always better to pass the variables. Almost all of our reports are structured this way. We have Statewide, Area, County, Supervisor and Worker levels in our reports. As a result, I have 4 & variables for Area, County, Supervisor and Worker. In my launch program, they are initialized to ALL. This way I can use the variables to tell which level be reported. For example, if Area is not ALL but County is ALL, I am at the AREA level and I dynamically adjust the selection and sorting (WHERE and BY clauses). If the user then drills down to a specific county in the Area in focus, I pass the Area and County but the Supervisor and Worker are still ALL.

jgolena: You're all over it! that's exactly what we do, except we're using the FOC_NONE to our advantage rather than your 'all'... IN FACT, for a few variables (who weren't used int he where clause, but needed to be passed) we had to use a value of 'IGGY' (short for ignore?) because I wasn't sure 'ALL' OR 'IGNORE' weren't reserved words.

It feels good to know that I'm not the only one doing this.

Jason, you are aware that using FOC_NONE as an amper value will make WF ignore the entire line of code?

The entire line will be ignored - you will get all rows:

-SET &COUNTRY = 'FOC_NONE';
TABLE FILE CAR
PRINT
*
WHERE COUNTRY EQ '&COUNTRY' AND SEATS EQ 4
END

You will get an error:

-SET &COUNTRY = 'FOC_NONE';
TABLE FILE CAR
PRINT
*
WHERE COUNTRY EQ '&COUNTRY' 
AND SEATS EQ 4
END

You will get cars with 4 seats:

-SET &COUNTRY = 'FOC_NONE';
TABLE FILE CAR
PRINT
*
WHERE COUNTRY EQ '&COUNTRY' 
WHERE SEATS EQ 4
END