Skip to main content

Interactive Report vs Interactive Grid: Key Differences Every APEX Developer Should Know

Hi Everyone! πŸ‘‹

Recently, I came across an interesting behavior in Oracle APEX that’s worth sharing.

I had a page containing two reports — an Interactive Grid (IG) and an Interactive Report (IR) — both based on the same SQL query. The query included a bind page item in the WHERE clause to filter data dynamically.

As per the requirement, I set the page item’s Storage Type to Memory Only. When the user clicks the Submit button (handled through a Dynamic Action), both the IG and IR regions refresh perfectly, and the data displays as expected.

However, I noticed something unusual: when clicking on a column heading in the Interactive Grid to use the built-in column filter dropdown, it displayed no values. On the other hand, the Interactive Report showed the distinct filter values correctly for the same column.

Note: To make the Interactive Grid column heading dropdown filter display values, the page item’s storage type must be set to Session State, not Memory Only. ✅

This behavior occurs due to a fundamental difference in how IG and IR handle filters internally.

I’ll browse and share a short summary of what I found:

  • Interactive Grid (IG) relies on an in-memory model for filtering, sorting, and dropdown value generation after the initial server query.

  • Interactive Report (IR) performs server-side queries to populate filter dropdowns, fetching distinct database values each time.

When a bind variable (your page item) is set to Memory Only, it is not persisted to session state — meaning it’s available only in the browser, not on the server.

Since IG uses its client-side model, it may lack the necessary data context to build dropdown filter values if the initial model doesn’t contain all possible distinct values.

In contrast, IR re-queries the database when building filter dropdowns, so it always retrieves up-to-date distinct values using the latest bind variable — even if that variable was Memory Only. ✅

FeatureInteractive Report (IR)Interactive Grid (IG)
PurposePrimarily for advanced data analysis, exploration, and reportingFor both reporting and data entry/manipulation, with spreadsheet-like and real-time editing features
EditabilityRead-only; users cannot directly edit data in the reportCan be configured as editable; users can add, modify, or delete records inline
Customizations by UserUsers can sort, filter, group, highlight, and define computationsUsers can sort, filter, highlight, lock/freeze/hide/reorder columns, drag-drop rearrange columns, and more
Aggregations & BreaksAllows aggregations, group by, charting, and breaks via Actions menuAllows aggregations, group by, and breaks, often with more flexibility
Multi-Row OperationsNo support for multi-row edit/operationsSupports multi-row select and operations, making bulk editing possible
Inline EditingNot supportedSupported (if enabled by developer)
Best Use CaseData analysis, exploration, exporting, ad-hoc queries, read-only presentationData entry, spreadsheet-style manipulation, transactional operations, data maintenance
Actions MenuYes (provides report operations)Yes (provides both grid and row-level operations)
Dynamic ActionsLimited supportExtensive support for dynamic actions and custom JavaScript
PerformanceGood with large data; server-side filteringOptimized for interactivity; may load more data into client side model for fast editing/filtering
File/Image/LOB SupportBuilt-in actions for file download/display of BLOB/image columns​; more straightforward with filesNot as straightforward; may need workarounds/plugins for BLOB/image columns
Save User SettingsUsers can save their report customizations as private/public reportsUsers can save modified grid layouts as private/public reports

Note: Some information has been gathered from OpenAI. Kindly reconfirm it with official Oracle APEX documentation as well.

Comments

Popular posts from this blog

APEX - Tip: Fix Floating Label Issue

Oracle APEX's Universal Theme provides a modern and clean user experience through features like floating (above) labels for page items.  These floating labels work seamlessly when users manually enter data, automatically moving the label above the field on focus or input.  However, a common UI issue appears when page item values are set Dynamically the label and the value overlap, resulting in a broken and confusing user interface. once the user focuses the affected item even once, the label immediately corrects itself and displays properly. When an issue is reported, several values are populated based on a single user input, causing the UI to appear misaligned and confusing for the end user. Here, I'll share a few tips to fix this issue. For example, employee details are populated based on the Employee name. In this case, the first True Action is used to set the values, and in the second True Action, paste the following code setTimeout(function () {   $("#P29_EMAIL,#P29_...

Building a Custom Debug Package for Oracle APEX Using PL/SQL

While developing Oracle APEX applications, debugging page processes and backend PL/SQL logic can be challenging—especially when values are lost between processes or execution flow is unclear.  Although DBMS_OUTPUT is useful, it doesn’t work well inside APEX runtime. To solve this, I built a custom PL/SQL debug Package that logs execution flow and variable values into a database table.  This approach helps trace exactly where the code reached, what values were passed, and whether a block executed or not - even inside page-level processes and packaged procedures Why a Custom Debug Package? Works seamlessly inside Oracle APEX page processes Persists debug information even after session ends Helps trace execution flow Captures runtime values Can be turned ON/OFF dynamically Does not interrupt business logic The Package consists of:- Debug Table                         -  Stores debug messages Sequence ...

Conditional Cell Editing in Oracle APEX IG

While browsing the Oracle APEX forum, I noticed a question from a user asking how to disable all other cells in an Interactive Grid row until the first cell has a value. In this blog, we will explore how to disable all other cells in an Interactive Grid row until the first cell contains a value. This approach helps enforce proper data flow, avoids incomplete or invalid records, and improves overall data integrity.  By implementing a simple client-side logic using JavaScript and Dynamic Actions, we can gain fine-grained control over row-level editing behavior in Oracle APEX. Step1: Create IG with static ID of EMP. Step2: Paste the following code in function global declaration. function setCellsToReadOnly()  { var grid = apex.region("EMP").widget().interactiveGrid("getViews", "grid"); if (!grid || !grid.model) { return; } var model = grid.model; model.forEach(function (record, index, id) { var meta = model.getRecordMetadata(id); var fields ...