Tabular Form: Conditional column based on another column in table/form?

Question

Hi!
I have 4 columns in table A:
number (the question number)
question (the question to be asked)
type (TEXT, LOV are the 2 valid values)
answer (the answer with text or a selection from the lov table below)
I have 2 columns in table B:
number (the question number)
values (a single value for the lov's)
In table B there can be mutiple rows for each number. Table A and table B
join on the number.
I want to build a tablular form on table A where for each row either a text
box or a select list is displayed depending on the contents of the type column.
So row 1 would display a text box when the type value is text; row 2 would
display a select list when the type value is lov.
Is this even possible? How do I refer to the type column in the conditional for the
answer column? I am guessing that I will need to have 2 answer columns one
that displays when the type column is TEXT and one that displays when the
type column contains LOV. This is OK. Setting up the conditional is display is the issue at this point.
Hopefully I have explained this well enough! :)
Thanks!
Dave Venus

Answer 1

Hi Dave,
Sorry for not responding sooner - I finish work at 3pm GMT.
I'll take your first question first (3:28PM posting according to my display - not sure if you are on GMT time?):
As far as I understand it, using the select_list_from_query() function generates the options that are required in the select list as HTML tags. Each instance of this function should create a SELECT tag and the results of the query should generate one or more OPTION tags within it.
Second question (4:20PM posting):
The HTMLDB_ITEM functions are listed in the documentation - here's a link to the online version:
http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14303/api.htm#sthref2524
Most of the examples that I have seen have been on this forum - simply search for HTMLDB_ITEM or one of its functions.
I tend to leave the generation of tabular forms to the wizard as much as possible. The only exceptions are when I need to have access to more than the Primary Key for a row but don't want to show the field on screen. There are examples on the forum about concatenating the HTMLDB_ITEM functions into a single value - this hides ID fields from the user but makes them available to PL/SQL code.
Third question (5:29PM posting)
I did try using DECODE in my questionnaire but not for the feature that you needed. Originally, I wanted to use this to display one of a number of different fields (ie, my date, number or string field as appropriate to the question) but this didn't help as I couldn't get back to the right field during the update. If you have decode working for the select lists, then that's great!
The first column should be hidden or sitting behind a checkbox as this should be the Primary Key for the row and should not be editable by the user nor would it normally be displayed.
As long as your select statement creates the correct output (albeit that you may need to work on the layout!), you should have an updatable form. However, you will need to have the MRU processes in place and the appropriate buttons that trigger these. When I did my questionnaire, I created the form using a wizard to get all of the processes and buttons and then changed the select statement. If you haven't got the processes and/or buttons, we can go through adding these onto your page.
Last question (9:08PM posting)
As explained above, column 1 should normally be hidden. The INPUT tag you detail above is what I would expect to see. The value="6" attribute indicates that 6 is the Primary Key for that row - every row will have the same tag but different values for the "value" attribute. So, if it is hidden and these are the tags you see doing a View Source on the page, then everything is correct.
OK. So now we have the data on screen and (hopefully?) we have the correct processes and buttons on the page.
The next step would be validation and update of the data.
Validation of the data can be handled by a normal page process - I can let you have example code if you want to validate the data (this will also explain how to loop through the rows - there are also methods that you can use to do this in javascript if you want). Updates should be handled by the processes and buttons on the page - again, if you haven't got these we can go through adding them in (although, if you haven't yet formatted your page, you may find it quicker to copy your select statement and create the page again using the same select statement).
ORA-20001 errors are user defined errors. Do you mean the "data has changed" errors? If so, you will probably need to include the MD5 checksum functionality (it's shown in the document linked above).
Finally, we'll keep this thread going so that you have all of your workings and my responses in one place, if that's ok with you?
Regards
Andy