rg_id := find_group('My group');
if id_null(rg_id) then
rg_id := Create_group('My_group');
gc_id := add_group_column(rg_id,'emp_id',number_column);
gc_id := add_group_column(rg_id,'ename',char_column,15);
v_rg_id := POPULATE_GROUP_WITH_QUERY('My_group','select t.employee_id,t.first_name from employee_mt t where t.employee_id in (103,104,106)');
v_lov := find_lov ('LOV_NAME');
now i have problem...whether i create first a lov and record group at design time or not????
if i create a lov and have the recordgroup column then what is the benefit of dynamically lov...???
it means that i must create and recordgroup at design time then if i needed another recordgroup which can be created at the design time.
i can add the column run time and then query the data to populated that column..how i can do this??
pls have a look at these video...
It is possible with some restrictions. Let's say you agree there are max 5 columns in your LOV-s. That way you can easily create LOV to RG colums mapping (what Andreas pointed out).
For example :
1. in design time create RG with dummy columns (for example : c1, c2, c3, c4, c5)
2. in design time create 1 LOV with 5 predefind columns (for example : c1, c2, c3, c4, c5)
3. populate that record group with select (selecting 5 columns. If you do not have 5 columns in your table on which LOV is based just select dummy columns for the rest of the columns) aliasing them as c1, c2, c3, c4, c5 (same as in LOV from step 2)
4. asign that RG to the LOV in step 1
5. in LOV show just "non-dummy" rows form step 3
The rest you already figured it out.
The benefit of this approach is questionable as the same can be done creating more RG and LOV-s in design time. So I believe this is the matter of developer preferences. By the way the concept I described we use on daily bases dealing with LOV-s.