Multi valued LOV - Display vs return

Question

APEX 4.2.1
On a form view, when there is a multi-valued LOV (checkbox, shuttle, multi-select list, etc), APEX item value in session state is a colon-delimited list and this is what gets saved to the varchar2 column in the database table. Assuming there is a simple lookup table to translate display/return values, on the report view for this data, how can this value (e.g. 1:2:3) be shown using the display values (e.g. One:Two:Three) instead?
Thanks

Answer 1

VANJ wrote:
Paul - I do agree and most of the time I am a stickler for proper database design. But for simple data-gathering exercises (think a typical customer satisfaction form with a bunch of questions, some of which are Choose all that apply ), creating itty-bitty tables (one per such column) for just this purpose seems like overkill.Would websheets be any use in that space? (Not something I've really looked into.)
Alternatively, one could simply setup the LOV to have the same display/return values and then the column could store One:Two:Three so the problem goes away.That was going to be my next suggestion.
But that would preclude the use of a user-editable LOV table where the user can change the display value(s) but keep the (stored) return value(s) unchanged.User-modifiable look-ups would be getting away from my definition of "simple data-gathering exercises" involving "itty-bitty tables".
Even if the data were to be stored in normal form, the report view would need to show 1 row regardless of the number of LOV choices, so the report query would have to use scalar sub-queries using string aggregation (e.g. LISTAGG function in Oracle 11gR2) of the form
select
(select stragg(m1.display_val) from detail1 d1, mapping1 m1 where d1.code=m1.code and d1.pk = m.pk) detail1,
(select stragg(m2.display_val) from detail2 d2, mapping2 m2 where d2.code=m2.code and d2.pk = m.pk) detail2,
from master mNot exactly elegant SQL, so then why be a stickler for normal form, just continue with the dirty hacks :-) Or am I missing something?And even less elegant when you add the code required to un-nest the delimited list. The last major APEX project I worked on use this [anti]pattern a lot (albeit using tables in proper normal form). I'm not keen on the resulting HTML structures either (unless they're nested lists). I was involved there too late to convince them to use some other presentation in the reports, but did manage to change the display value aggregation from using custom PL/SQL functions with cursor loops to inline SQL using <tt>xmlagg</tt>. (Since most of the time these display values were links some inelegant SQL and violation of separated concerns was involved. <tt>xmlagg</tt> has some benefits over <tt>listagg</tt> in this use case: works on 10g; semantic HTML for the aggregated values (e.g. lists) can easily be produced using SQL/XML; aggregates larger than 4000 byte VARCHAR2s can be returned using <tt>xmlserialize</tt>. The report break formatting enhancements detailed in Feature Request ABPF are badly needed to enable this kind of thing to be done declaratively.)
So....is there a way to have my cake and eat it too? Off-the-wall, unhinged, untested, and almost certainly very inefficient brainstorm: create a view consisting of a column with every possible combination of the value columns and another with the corresponding display value combination, and perform an outer join on the aggregated values...