We use DrillMenuItem to many levels and have become aware of the limitations of the URL in a drill.

We build our drill logic dynamically (in part).

FOCEXEC=DX (
&LNK_LOC
<15 MORE ITEMS>
)$
WHERE:
&LNK_LOC = USER_SEL_LOC='&USER_SEL_LOC' \
&USER_SEL_LOC = 13 OR 9 OR 14

***The drills work great***

However our URL character limit is reached prematurely. Upon inspection of the URL we see (again in part):

&USER_SEL_LOC=12%20%20
or
&USER_SEL_LOC=12&%09=%09=&USER_SEL_XXX

I've tightend up the &LNK_LOC and &USER_SEL_LOC by removing spaces (%20 hex), = signs, & signs and tabs (%09 hex).

The translation of a space to %20 in a properly formed statement is a 1:3 loss of character. The multiple spurious %20 and %09 and the occasional \\= is stealing too many characters.

Please, I welcome advice, suggestions and techiques from those who may have dealt with this situation already.

Thanks

This message has been edited. Last edited by: WF8Developer,

If you search on this there are a couple of examples where an JS file is used to consolidate the values at run time to ensure that the drill menu items are small enough so that the menu appears, and the report submission is done using a POST. The examples I posted are quite old, so I suspect that you will have to make some changes for it to work. The POST removes any concern about query sting size.

here

One last thing. A couple of weeks ago I ran into the same problem with another customer, and I am a little tired of using JS to solve all of my problems. So, I made the following assumptions:

- In all of my multi-drills, there are some constant variables that apply to every drill. Typically these are associated with a HTML launch page. All drill downs are associated with that. I decided that it was foolish to keep added the constant variables to every drill down (not to mention it was a lot of work).

So, on the first report from the launch page I added code like this:

APP FILEDEF VARS DISK foccache/vars.fex
-RUN
-WRITE VARS -SET &|VAR1='&VAR1';
-WRITE VARS -SET &|VAR2='&VAR2';
...
-WRITE VARS -SET &|VARx='&VARx';

Now, in the drill down reports I then included the vars.fex and there was no need to keep repeating the same variable settings in the drill down requests. If the reports are MRE based, then you include using:
-MRNOEDIT -INCLUDE VARS

This method proved to be very easy and useful, and saved a lot of time on the down stream drill reports.

Even worse, passing those variable names and values on between the server and the client all the time is absolutely pointless if the user can is not supposed to not change them. It's just wasted bandwidth.

The usual solution for such data is to put them in the session on the server. What's the equivalent for that in WebFOCUS? Global variables?

Another way to avoid passing the same variables would be to do do a hold file by applying the filters from the html file and do a foccache on the hold file. Your drillmenu items would go against the hold file instead of the actual table that need to process all the parameters again.
Example:
-IF &RPT_DD EQ 'Y' THEN GO TO DRILLTBL;
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ '&COUNTRY' --params from html file
ON TABLE HOLD AS HFOCCACHE/HRPTOUT
END
-RUN

-DRILLTBL
TABLE FILE HFOCCACHE/HRPTOUT
PRINT *
ON TABLE SET STYLE *
--Drillmenu items style commands
ENDSTYLE
END