This discussion is archived
6 Replies Latest reply: Aug 1, 2005 6:59 PM by 60437 RSS

htmldb_util.set_session_state not working

VANJ Journeyer
Currently Being Moderated
In ony of my after submit processes, I have
if :P1_ACCNT_NO is null then
  mypkg.create_account;
end if;
In the create_account procedure, I do
htmldb_util.set_session_state('P1_ACCNT_NO',v('P1_REAL_ACCNT_NO'));
write v('P1_ACCNT_NO') and l_accnt_no to a debug table
The page has a unconditional branch back to itself

The values in the debug table are fine but when the page refreshes, P1_ACCNT_NO is still blank in session state.

When I change the page process to
if :P1_ACCNT_NO is null then
  mypkg.create_account;
  :P1_ACCNT_NO := :P1_REAL_ACCNT_NO;
end if;
it works fine i.e. P1_ACCNT_NO gets the proper value in session state.

Any ideas why setting the value in my stored procedure is not working?

Thanks
  • 1. Re: htmldb_util.set_session_state not working
    60437 Employee ACE
    Currently Being Moderated
    Vikas - Try changing the process to:
      if v('P1_ACCNT_NO') is null then
        mypkg.create_account;
      end if;
    If that works, I'll try to explain why.

    Scott
  • 2. Re: htmldb_util.set_session_state not working
    VANJ Journeyer
    Currently Being Moderated
    Yes, that does work! Can you explain why? I shouldnt need to use v when the process code is inside the Edit Process page itself, right? Thanks
  • 3. Re: htmldb_util.set_session_state not working
    60437 Employee ACE
    Currently Being Moderated
    Vikas,

    It's kind of a quirk in how bind variable notation is used to map values back to session state. In your code:
      if :P1_ACCNT_NO is null then
        mypkg.create_account; /* this procedure changes P1_ACCNT_NO in session state */
      end if;
    ...the engine parses the block, keeping track of bind variable names which it initializes with the current value of the corresponding items from session state. Then it executes the block dynamically and as the last step updates items in session state whose values are not the same as post-execution values of their corresponding bind variables. This allows statements like :P1_X := 'foo' or my_proc(:P1_X /* out */); to actually change the value of P1_X. In your example, the item P1_ACCNT_NO is updated after the block is executed based on the same rule -- the bind variable and the item value are different, not because the bind variable changed, but because the item changed.

    So to answer your second question, you shouldn't need to use v but in these rare cases, you do need to. We'll either fix this or document this behavior to prevent others from running up against it.

    Scott
  • 4. Re: htmldb_util.set_session_state not working
    VANJ Journeyer
    Currently Being Moderated
    Scott, thanks, I tried really hard to understand that explanation, but couldnt really get it.

    Could you explain again, why, even though I set session state using set_session_state in my package, P1_ACCNT_NO is not set at the end of the process? As per your explanation below, after the block is dynamically executed, P1_ACCNT_NO (1234) in session state is the same as post-execution value of :P1_ACCNT_NO so it is not updated. But then why dont I see this value 1234 in session state (I see blank which is what it was before the process was fired)

    And why does using v() notation instead of :bind notation change the behaviour? [I guess this is because using v() "fools" the engine into thinking that session state is not involved so it doesnt do the "post execution" step you refer to below?]

    Thanks
  • 5. Re: htmldb_util.set_session_state not working
    VANJ Journeyer
    Currently Being Moderated
    but in these rare cases, you do need to.
    Just so I understand, what rare cases would these be? Processes which call a packaged procedure/function that uses htmldb_util.set_session_state to set session state?

    But I have used set_session_state extensively in my applications and have never run up against this behaviour.

    Thanks
  • 6. Re: htmldb_util.set_session_state not working
    60437 Employee ACE
    Currently Being Moderated
    The bind variable associated with :P1_ACCNT_NO starts out as null because it is obtained from that item's session state. After execution of the block the bind variable value (still null) and the item value(1234) are not the same, so we update the item with the post-execution bind variable value, which is still null. That's the bug, we should compare the pre-execution bind variable values with their post-execution values without making the unreliable assumption that the item's current session state value is still the same as the pre-execution bind variable value (it is in most cases, except when you use the set_session_state procedure or when something else changes the value underlying a named item, as in the case of the :APP_SESSION/v('APP_SESSION') problem on the login page that you may recall). And you're right, using v() gets around the whole issue because access to session state is entirely read-only.

    Scott