We are using HTML Composer with WebFOCUS 7.7.03. We are aware there are certain limits on the amount of parameters that can be passed to a fex or that a fex can handle. The total length of all variable values cannot exceed 32K. Internet Explorer 8 has a maximum URL length of 2083 characters and IE had a limit of over 5,000 (I think). We’ve seen what happens on drill downs hitting the URL length limit where the drill link quits working. That isn’t so bad to accept, but what errors do you receive when a large number of parameters are selected on a launch page say over 2000 characters (we are in IE 9) (in my case from one parameter selection – multiple customer numbers). We are not hitting a browser limitation in this case. I’m receiving a (FOC 206) INSUFFICIENT MEMORY IS AVAILABLE FOR PROGRAM/CACHE. I’ve submitted a case to get more information on this as I’m not sure if there is something that can be done to prevent this specific error. It is unlikely that someone would really need to run a report with so many parameters selected, but we have had the error brought up to us by a user on one report when a large number of parameters were selected which reported some style sheet error. I do not ever, if at all possible, want a user to receive a hard error without providing them some direction on how to correct the issue.

Are there any strategies to catch these errors caused by too many parameters in order to produce a friendlier message to assist the user, and are there a standard list of errors this can cause in the fex?

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

First thing is to ameriorate the problem. Suggestions:

1. Keep the parameter names and the internal values returned by the launch page short. (For the droppdown entries, you can use sequence numbers, encoded as 1 or 2 or (gasp) 3 base-62 digits using [0-9,a-z,A-Z].)

2. If the drilldown report needs all the original report's parameters (plus others), consider caching the original parameters in a database structure, and just passing a retrieval token. If you store them as a set of (name,value) pairs under a unique token value, it is pretty straightforward to write a utility fex that will re-establish the variables via generated
-SET &{name}={value};
statements, so the called report fex can access all the parameters as local amper variables.

As to trapping the error, that's pretty hard for the called report fex to do -- there's no telling where the stream of information will be truncated.

You might pass a trailing parameter, and check whether it is received. If it fails to show up, the fex knows that the game has to be called.

(Of course, excessive parameters might still cause something to choke upstream, and the fex never gets control. Stress testing should reveal whether that can happen. If so, then you need to take preventive action within the launch page, to stop the music if too many values are selected.)

This message has been edited. Last edited by: j.gross,

To overcome the URL length issue, you should use a FORM and POST the values, from an HTTP perspective, there is no limit.

When doing drilldowns that could prove to be a little hard.
With drilldowns, when you let the stylesheet take care of it, you do not have very much control over the length of the generated url and such. If this is the problem, you'd have to revert to coding your own drilldowns, using javascript to possibly create a form, populate it and send if off to the intended receiver.

GamP: Ah, but if the launch page uses a form, as Warren suggests, then the initial report can then cache the parameter pairs and use standard drilldown syntax, effectively paring them all down to a single parameter (the retrieval token), as I suggested above.

I'm hitting restrictions prior to drill downs. For example after using the SQUEEZ, every use of the parameter after that is blank. I couldn't find anything mentioned about a limitation on it in the help, but that's one case. I know STRREP has a character limit. I wish some automatic error could be turned on if the user ends up passing parameters that the FOCUS can't handle.

We do a lot of scheduled reports so caching parameters to work around drill downs isn't really an option or at least we don't want to face the complexity of what it would be to work in that case.

Our standard tool is HTML Composer as well so I don't want to start changing how the HTML form submits the data to the FEX.

All I really want is an easy way to return an error not to work around these restrctions.

Anyone ever used the GETHEADR function? It looks promising, but I can't get it to return anything.

We added javascript that can be used to validate our large selection options (such as customer)that will throw an alert to the user if they exceed whatever limit we decide without running the report and bombing. Went with 2400 characters since they wouldn't be able to export over that anyway. The WebFOCUS functions I've been using can handle 2400 characters.

We also added code to count up the total length of all characters used for drill downs or exports so that when selections from multiple options exceed 2400 characters, we can provide a nicely formatted error page instead of bombing.