Skip to Main Content


Interactive Grids issues with PopupLOV with multiple values, and CRUD functionality consuming ORDS

GuilleCLMar 24 2022

1) Using PopupLOV inside an Interactive Grid:
- Interactive Grid is consuming an ORDS.
- One of the column’s type is PopupLOV (which at the DB level is a Varchar2 using a “Listagg”).
- The PopupLOV is consuming a LOV with variables of the same type as the column type (Varchar2).
- I have an assignation process in my DB to do assignations in intermediate tables (this method inserts the id of the object of the grid row with every id of the objects concatenated of the PopupLOV).
* The PopupLOV doesn’t correctly separate the variables I put in it (ONLY IF I USE THE IDS), which I select from its internal LOV, neither the variables that it’s getting from the ORDS; but if I use the names of the variables both in the PopupLOV and in its internal LOV using “name” as display and return as in the following example:
* Select id, name (display value), name as name_2 (return value) from #APEX$SOURCE_DATA# where object_type = ‘x’.
* Putting this code in the “Post Processing Type SQL Query” in the LOV is the only way for the PopupLOV’s “Search as you type” field to work.
* If I use the LOV with the return value as id and the display value as name, then when the Popup has more than one id it doesn’t correctly separate the “objects” and doesn’t display the names correctly; but IF I USE THE NAMES, I have to convert them to ids to do the assignation/insertion in the intermediate table, so the process is not very efficient but this way it works.
* So, I wanted to know if there’s a way to consume the ids with the LOV, so the PopupLOV separate them correctly.
*A pretty similar example to this situation I am facing is in the IG Cookbook 19.2 v6 (John Snyder) in the “Autosave page (entry of the Navbar)” but it is just the PopupLOV with single values not consuming an aggregation list (“Listagg”); the IG Cookbook 19.2 v6 can be downloaded here:

2) Using the save button of the Interactive Grid (“CRUD” operations):
- The save button calls a POST, a PUT or a DELETE depending on the action performed; and I have been using an ORDS which the Grid is consuming.
- The ORDS consumes a typical database an its packages’ procedures, etc.
* I tried both using a “:body_text” in the ORDS doing all the parsing there and calling the function I want to use, in this case the “Insert” function with a POST; and I tried too, using a “:bodytext” just calling to the DB “Insert” and doing all the parsing at the DB with the apex_json.parse, apex_json.get_varchar2, etc; but none of that seems to work properly; in this last/second scenario at least the Grid does the insertion correctly but the “IG - Automatic Row Processing” process generated automatically when enabling the edit functionality of the Grid, tries to call the POST operation two times; the first POST with the correct data for the new row added and the second POST with no fields/information.
* I have been trying to do it without parsing and without using :body_text in the ORDS, and just using HTTP HEADERS but it doesn’t seem to work either.
* So, I want to know if I need to change the “IG - Automatic Row Processing” process generated automatically when enabling the edit functionality of the Grid, and if it’s obligatory to use a PL/SQL Query to work properly to do the CRUD function correctly, like it’s showed in the following link:

Post Details
Added on Mar 24 2022
1 comment