Passing Parameters to a discoverer folder using Note 282249.1

Question

I am creating reports for a multi-lingual environment. My problem is trying to present the headings in the reports in the language required. Since I am creating all the code for the reports in custom folders, I thought I would just hide my column headings using color on color and add a row to my report that is a headings row.
In order for the headings row to display, it must have the value for the parameter I am using...a type of id. I followed the instructions in Note:282249.1 for passing a parameter to a discoverer folder. It works perfectly...sometimes. I think the 'sometimes' has something to do with caching.
As the Note says, I created a function 'setparam' and then I created a condition in the report which is 1=SETPARAM(:my_parameter). Here's how I ran the report and the results:
1. Condition in the report, heading row doesn't display
2. Remove the condition, use the same parameter, heading row displays
3. Condition still not in, use new parameter value, heading row doesn't display
4. Add Condition back in, same parameter value as #3, heading row displays
5. Remove condition, same parameter value as #3 & #4, heading row displays
6. Add Condition back in, same parameter value as #3, #4 & #5, heading row displays
7. Condition in the report, new parameter value, heading row doesn't display
8. Results same as #2
and so forth. Which is why I decided it has to do with caching.
So then I ran the sql in SQL Developer and got this error. "SQL Error: Missing IN or OUT parameter at index:: 1". I googled the error, but the results are outside my scope of knowledge.
Anyone?
Thanks so much,
Tricia

Answer 1

Hi,
It is difficult to use this technique with the /BATCH command because you cannot specify the order in which the worksheets will be processed.
My suggestion is that you change you set_context function so that the value is stored in a table and then create a logon trigger so that the users' contexts are reloaded when the user connects. Your contexts will then effectively be permanent and reset from session to session.
You will need to create a table to store the contexts:
CREATE TABLE disco_user_context
(username VARCHAR2(30), attribute VARCHAR2(30), value VARCHAR2(4000),
CONSTRAINT disco_user_context_pk PRIMARY KEY (username, attribute));And modify your set context function to store the contexts:
FUNCTION set_context(p_name VARCHAR2,
                     p_value VARCHAR2) RETURN VARCHAR2
IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
dbms_session.set_context('EUL_DISCO', p_name, p_value);
INSERT INTO disco_user_context (username, attribute, value)
VALUES (user, p_name, p_value);
COMMIT;
RETURN p_value;
EXCEPTION WHEN DUP_VAL_ON_INDEX THEN
UPDATE disco_user_context
SET value = p_value
WHERE username = user AND attribute = p_name;
COMMIT;
RETURN p_value;
END set_context;Then create an initialization procedure in your package:
PROCEDURE initialize
IS
result VARCHAR2(4000);
BEGIN
FOR contexts IN (SELECT attribute, value FROM disco_user_context WHERE username=user)
LOOP
    result := set_context(contexts.attribute, contexts.value);
END LOOP;
END initialize;And create a logon trigger to call the initialization procedure:
CREATE OR REPLACE TRIGGER rodwest.disco_logon_trigger AFTER logon ON rodwest.SCHEMA
BEGIN disco_pkg.initialize; END;
/Hope that helps,
Rod West