This content has been marked as final. Show 22 replies
Re: pk = P9_PARTICIPANT_NUMBER
I don't see "PARTICIPANT NUMBER" on the form. So, it's hidden right? When a selection is made, the PK (:P9_PARTICIPANT_NUMBER) needs to be be assigned and the value set. On my select list, the "Settings" "Page Action When Value Set" is "Redirect and Set Value". But in addition, I believe you need a Dynamic Action based on the changing of the Select List and that Dynamic Action needs to submit the P9_PARTICIPANT_NUMBER value.
I believe it's the case that if it isn't submitted, it's not in the session state yet and your buttons will be looking at the "prior" session state value. How about displaying P9_PARTICIPANT_NUMBER on the page for debugging purposes. And see if the same value that's displayed is what you see in the session state? If they differ, the session state has not updated yet. And your tests will be checking the un-updated session state.
I went round and round and round with this early on because I could see the value right there on the screen -- but that was NOT the value that was being tested! And default values aren't immediately placed in the session state either. They appear in the HTML -- and on the screen but they don't immediately commit to the session state "on their own" so to speak.
Indeed the PARTICIPANT_NUMBER is hidden. Some odd things happen when you set it visible (for example 'display only'). By setting it visible a 'no data found' exception raises when you re-open the form. That is: you switch over to the builder menu, alter something, and then run the page again .... => "no data found". It must be raised by the 'fetch row process' that is supporting then rendering of the page. Because it is displayd the form (an HTML object) expects a value to be entered, but because it is 'display only' no value cant be entered. Again you are stuck ....
Yes, your are exactly right about the part of the 'prior' values too. I still can't find a solution for that. Sure I can apply a handful of dynamic ations under the select list. In fact I already did ;)
I can even apply a 'submit page' but then all items are set to null again. (Something that is not in line with the documentation about the 'submit').
If you want I can show you a perfect example of a form that shows "a value <b>prior</b> to the <b>current</b> retrieved" ....
! ! ! ! ! !
Have you noticed that for DISPLAY ONLY items, there is a "Settings" "Save Session State" that can be set "No" or "Yes"? It defaults to "No" so that value is never saved and tests on the variable will NOT give you what you probably want!
And HIDDEN items have a "Settings" "Value Protected" which I don't fully grasp.
(more) There ought to be a book: "APEX Gotchas" that lists these subtle features. I'm reading about subscribing, unsubscribing and publishing in "Managing Themes and Templates". I hope to learn the answer to "Why and when would I need to?" It's not enough to know "How".
As I tell folks, I push keys for a living. But I don't get paid to push the keys. I get paid to know WHAT key to push WHEN.
I get 1 error has occurred ... cannot insert null into ... ACCOUNT_NUMBER. And Account Number 5 shows on the screen. So I'd presume that the "5" never made it into the session state for ACCOUNT_NUMBER. So, it's null in the session state! The generated value needs to be placed in the session state. But "How?" asks our intrepid application designer. And "Why?" should this be so hard? Time to ruminate. Stay tuned boys and girls for our next exciting adventure!
(more ...) Account Number (display only) is set to "Save Session State" "Yes", right?
ACCOUNT_NUMBER is the primary key, right? And in the page item that holds it, you have defined
-- "Source Used" "Always, replacing ...." and
-- "Source Type" "Database Column" and
-- "Source value or expression" "ACCOUNT_NUMBER"
Check out Page_4 now. Some me an email and I'll try to send you the code!