This content has been marked as final. Show 16 replies
I changed your page 21 a little bit. I hope this is okay.
Item P21_CUSTOMER_BANNER was defined as a text field, but with a Read Only condition of "always". For all practical purposes, this is really an item of type Display Only with "Save Session State" of "No", which is what I changed it to. The page seems to work now. Can you please check it out?
Also, I changed the password of the guest account, to avoid the world from logging into your workspace.
Joel, that was perfect, sir. Full points given.
If I may ask... How did you know to look there? And why would it have suddenly become broken?
Hi Mark,1 person found this helpful
I was able to determine the affected item by the item ID given in the error message (130073351461551152955). That error message will be changed to include the item name instead.
Also, I know that this is slightly modified behavior in the forthcoming APEX 4.1.1 patch set, which will be documented in the patch set notes.
Joel, thank you again for the detective work.
For future reference for everyone else, what Joel did was cool, but I didn't know how to do it -- how to find the object associated with that long ID string. Here's how:
In the SQL Workshop > SQL Commands, execute this query: select item_id, page_id, region, item_name from apex_application_page_items where item_id = '12345678901234567890'
using the ID string from your error message.
And now what would be the trick if he would have to use value of P21_CUSTOMER_BANNER in his next page ?
I am experiencing the issue and can't find any solution.
Maybe you need to change "Save Session State" to "Yes"?
thank you for the answer.
Already tried this and get the same kind of session state violation error.
I have the same problem. Apps falling over everywhere since the 4.1.1 update was applied.
2 separate problems, one relating to zero session ID usage, which used to work fine, and also a common thread of display items with session state set to save as reported in this thread. Not sure how often this technique has been used, I have hundreds of pages to check - but it was valid before, and perhaps a query ought to have been made available to run before applying the patch. Or even now would be good.
My hosting service have shrugged their shoulders and left me to it. Five days of severely compromised operations from avoidable problems it would seem. Thank you Revion.
Can you please provide more information what is not working related to the usage of zero session ID. Might be a good idea to open up a new thread.
Regarding the "Session state protection violation" problem, I can offer that I have a look at your application to identify the root cause of the issue. You can send me some instructions and login information to patrick dot wolf at oracle dot com
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Thank you Patrick, I would very much appreciate your input, and I have sent instructions and credentials via email.
Some items in question map to database columns within the scope of a page's standard apex DML routines. These page items need to be saved to the database even if their value is established by page events and processes other than user input. I guess I could set their session state by stealth, and submit them in a report region refresh, although there is no guarantee this would work if you are dynamically generating a minimalist SQL update statement. I think the previous approach - allowing the developer to specify the items to be saved - has a lot to commend it.
I recently discovered that my fallback plan to use the "set_compatability_mode" procedure to revert to 4.0 compatibility mode, appears not to resolve this particular problem. Reverting to a server which has not run the 4.1.1 update DID fix the "session state protection" error, but this option is not viable beyond the next few days.
Since other people might have the same issue, let me add my situation (after the upgrade from 4.0 to 4.1.1.00.23).
We have several hidden items that got this message after the upgrade, and didn't get it before. The problem in this case is the "Value Protected" property. It was set to Yes, which apparently didn't work properly in 4.0. Setting it to No resolved our problem.
I have the same problem with fields that are read only and displayed as Text Field. All I had to do to fix the problem is click on the 'Text' item below the Display As field.
That is friggin obscure!! How in the world did you figure that out? And why does it work?
I have the same problem with fields that are read only and displayed as Text Field. All I had to do to fix the problem is click on the 'Text' item below the Display As field.<<
Joel, how are you? I have to admit to not reading the documentation and stumbling into this because it stopped working just like the others. But it sure is comforting to be able to find the answers on the forum. Thanks for the great work you guys always do!
Edited by: sk**** on Sep 6, 2012 4:32 AM