I made a very simple form in Apex, containing 5 items that consist on a database table called Participants. 5 columns like primary key, first_name, last_name, creation_date and description
I added one item extra on the form: a SelectList. The SelectList has to retrieve all participants and then - by changing or setting the value in the selectlist - the form has to synchronize with that value in the selectlist. I added some extra coding in a dynamic_action attached to the SelectList. PL/SQL coding contains something like
select participant_number, first_name, last_name, description, creation_date
where participant_number = :P9_UPDATE;
The :P9_UPDATE item is the SelectList.
You can see the behaviour at
login in with user/pw = exam_demo/demo
It works rather nice but ... I did <b>not</b> comprehend the mechanism of SessionState behaviour some how. The regular items get refreshed after selecting the new value in the select list, but the page itself wont render from starting point and wont switch over to the mode in whitch I can "Apply Changes". The "Create" button stays active and the button "Apply Changes" does not become available.
How to approach this?
Kind Regards Richard
Edited by: richard_dirksen on Jan 28, 2013 5:15 AM
I implemented an extra 'Clear Cache' under the Cancel button. When you click 'Cancel' you will have to see a cleared form and a new record can be inserted. That part works properly (so far). I will investigate your solution.
Yes I can access your url en see your application, however im not able to access the builder menu, so i cant see the code that's behind it. I do have a feeling about your solution though. I guess you implemented some sql or pl/sql - via a dynamic action - behind the "Query" button. After triggering that button the values are retrieved from the database and the corresponding values are set in the items "St" and "StNum". I nice solution, but still you will have to make use of a report to see all data that is already in the database.
Setting up a report and then creating a link that is refreshing (synchronizing) the values in your form is another way to handle this. I already accomplished that. But still I want to skip the 'report' solution and want to set op an item in the form itself (by using that SelectList). Im still hoping to grasp the concept of the mechanism of the SessionState ....
Are you able to use the "cancel" button in my app and claer the form (and then insert a new record ...)?
It's set up as a developer account. I was hoping it gave developer access but now I'm not sure how. I'll have to check.
Yes. I can now add and update a record -- without using cancel.
On my application, the Query button does NOTHING but Submit the Page. Then ARF does the retrieval -- by primary key value -- because that's it's job. It retreves what's in the primary key. I do have a "post Cancel" process that sets the primary key to NULL so that ARF does not requery the record to the screen.
(more) When I log in with these credentials, I have the developer toolbar at the bottom of the page. ???
Does that help?
Edited by: Howard (DBA in Training) on Jan 28, 2013 1:42 PM
Thanks for your reply. And thank you about he clearness about the 'submit page' behind your button.
Basically I set up my application the same way you did. Automated Row Fetch (ARF) and Automated Row Processing (ARP) are both there. There is an option to trigger an 'submit page' in the SelectList too. But when I do that all items are set to null (even in the session browser I can see that). I will try to acces your appl again and give feedback.
I don't understand how you want use the Select List. It seems to me that it works. 1) I can submit new records and I can update existing item descriptions. (I can even update First and Last name.) What more did you want? What did you want to happen when a name was selected. (Personally, anything triggered on a select list needs to be reversible for guys like me with old eyes and tri-focals. I get the wrong line now and then. ???)
Seems we are stuck in some kind of a twilight zone.
I want the form to do this:
a. when it opens all items should be cleared
b. you should be able to create a new participant, just by entering first_name, last_name etc and then click the create button
c. when you are facing a cleared form you should be able to retrieve existing participants via the select list item
d. after a successful retrieve the 'create' button should be unavailable (not visible) automatically and the 'apply changes' button should be available (visible) => updates on the retrieved participant should be possible from that moment on
a. and b. work fine; no problem there ...
but c. and d. won't work as expected ...
Okay. You want the CREATE button to disappear when any of the fields are not null, right? So, have you set the button"Conditions" attribute? For my CREATE, it's set with "Value of Item / Column in Expression 1 is NULL" and I have P3_RCD_ID in Expression 1 -- it's the primary key. I have the oppposite for the SAVE button (your APPLY CHANGES button). So, the create button only appears when the page renders with null PK. After an APPLY CHANGES, and ARF retrieves the updated record, CREATE is not displayed. But APPLY CHANGES is because PK is not NULL -- in my case.
On other appls, I get more sophisticated. I don't have a button condition, so the button is always there. But I enable or disable (grey out) it depending on these conditions. For that, I place a variable in the button attributes which I compute to '' (null) or 'disable' in the Page Header process. When it's '' (null), it's enabled.
-- sorry I was held up --
All options you described concerning the "when item x is NULL" and - opposite - "when item is NOT NULL" are implemented. In fact they are generated default when you walk through the wizard creating a new form. So im still wondering why this behaviour is not as expected ...