This content has been marked as final. Show 30 replies
You realise that in your tab_casc_sel_list_area process you have:
An extra > at the beginning - not sure what affect that may have on the rest of the code?
Umm... strange that it stops the code from working. Oh well.
I'm having great "fun" with my tests.
So far, I have a single record form and a standard (ie, wizard-created but tweaked) tabular form working ok with cascading LOVs:
1 - What's your reason for using PL/SQL to generate the form?
2 - How static is the data underlying the LOVs (ie, does it change often, rarely or never?)
Could I get access to your app like last time?
so glad you are having fun! I can only imagine it has been equal to mine. :)
I am using pl/sql to generate the form because of a couple of reasons: I intend to eventually have the second collection (efforts_C) be a tabular form (with many rows). This would mean that the page has 3 collections, two of which are tabular forms and each of those tabular forms has cascading lovs. It was my understanding (and again, I am pretty new on this) that in order to have multiple tabular forms, I would need to use collections...and the cascading LOVs enforced that belief.
Good question on the static/dynamic LOVs...In the instance of AREA/SUB AREA they will not be longer than 25 values and those values are fairly static, however, they are based on the combination of distance_code (c020) and state (c021) so in a sense, they are not truly static lists.
does that help. again, thank you!
ps. i will check out your test
Yes, as I understand it as well, multiple tabular forms have to be handled via collections as you specify the column numbers in batches - say, 1-10 for the first form and 11-20 for the second and so on - with the first column in each batch being the checkbox. This way you can identify which record relates to which underlying table.
So far, my tests have concluded:
1 - It is way easier to start with a simple select list that is based on "select null d, null r from dual" and allowing for extra values. Then, using calls to Ajax, generate the select lists based on whatever values are in the rows. This would also get around the issue of CLOBs
2 - It is simpler to pass all necessary filters to the application process rather than to try and handle them in the select statement using complicated case or where clauses - ie, let the process handle it, just pass it whatever it needs to return the correct select list options
4 - Creating tabular forms entirely from scratch is a pain in the ****! Do you ever need to add records?
Hi Andy, I was just looking at your example! thanks. What would happen if selecting from LOV1 yielded no rows pulled from LOV2 and from LOV3 you wanted all additional rows that are not tied to LOV2, so if you had a column lov2 in your LOV3 which was null.
do you see what I am saying.
thanks again. Karen
The fact that no rows would appear in LOV2, just means that the value of LOV2 is null or -1 or whatever we want an empty value to be. The filter for LOV3 would then just be whatever LOV2 key on that table matches null or -1 etc. ie, it's just another value to filter against.
Either way, I can let you see all the code etc that I have used in my app and you should be able to update it to fit your tables/columns. The only page I had any trouble with is the last one - and that's only because I seem to have broken the links to the insert/update/delete mechanisms showhow. All the other pages were fairly straightforward as they are all created using the wizards.
Just let me know how to want to proceed and we'll go from there.
Hi Andy, thanks again...and thank you for the Ajax encouragement!
I took your suggestion (and Denes') and created a simpler page...with just the one effort_c on it.
I am now able to get the cascading lov to work when the second lov (c021) is null...or a 'dummy' value that I have placed in the table.
now...it works on my simple page, but not on my more complex page and I think it has everything to do with the scripts in my page header. I eliminated most of the functions in my test page and perhaps that is why it is working?
Is there a way I can check to determine if a function is being called?
ps. I would also like to see the code you have written, if it makes sense, I can provide you access to my workspace...but let me know what you think.
really...you have been tremendous!
You should definitely try out Ajax in your applications - it is an extremely useful functionality as pages are much slicker because you don't have to submit the page just to change one thing on it.
alert("Here");if you mean the application process, then I find the simplest method is to generate an error. Add something like the following into your pl/sql script:
raise_application_error(-20001, "Here");This stops the rest of your code from running but at least you know that it is running.
yes, I will try the Ajax! I think most of my hesitation is that this application is so behind and users are clamoring that I just need to get it up and going....slick will be the next version. :)
thankyou! I owe you a beer.
Sure, it'll have to be tomorrow now as I'm about to close down for the day.
I don't drink - but may need to soon!
perfect. thanks again.
Right, I've added in a Notes page and a Documents page.
The Documents page contains everything you need to install my sample application (probably on your OTN workspace?). You even get stuff you need to create your own document upload/download functionality as it's part of the app now!
The Notes page contains details of what I have done for the Standard Tabular Form pages.
I agree with the original thread, when an LOV is set back to the supposedly null value it correctly displays the null replacement,
but the actual value in the item is a literal %null% which the documentation specifies as the null default here.
I sent the values to the database via a pipelined table function and wrote them to a log table there....the resultant values are not true nulls, especially if you use them for anything.
In pl/sql these values can be forced back to null, so function calls from the lov will still work, but any front end queries or conditions that evaluate this for null will fail. I suppose the conditions can use pl/sql expressions to see if :page_item is null or :page_item = '%null%' but this is ludicrous.
If you force the item to null with a process/branch it really becomes null, until you select something and then select the null option..
This actually wreaks havoc all over apex and I understand why people started using z or whatever as the null replacement.
Not to be snippy about this, but perhaps the product manager for apex should talk to Brynn Llewellyn and get some advice on the meaning of null.