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 reporting​For both reporting and data entry/manipulation, with spreadsheet-like and real-time editing features​
EditabilityRead-only; users cannot directly edit data in the report​Can be configured as editable; users can add, modify, or delete records inline​
Customizations by UserUsers can sort, filter, group, highlight, and define computations​Users 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 menu​Allows aggregations, group by, and breaks, often with more flexibility​
Multi-Row OperationsNo support for multi-row edit/operations​Supports multi-row select and operations, making bulk editing possible​
Inline EditingNot supported​Supported (if enabled by developer)​
​
Best Use CaseData analysis, exploration, exporting, ad-hoc queries, read-only presentation​Data entry, spreadsheet-style manipulation, transactional operations, data maintenance​
Actions MenuYes (provides report operations)​Yes (provides both grid and row-level operations)​
Dynamic ActionsLimited support​Extensive support for dynamic actions and custom JavaScript​​
PerformanceGood with large data; server-side filtering​Optimized 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 reports​Users 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

Post a Comment

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_...
Post a Comment
Read more

Oracle APEX UI Tip: Display Page Title Next to the APEX Logo

In most Oracle APEX applications, every page has a Page Title displayed at the top. While useful, this title occupies vertical space, especially in apps where screen real estate matters (dashboards, reports, dense forms). So the goal is simple: Show the page title near the APEX logo instead of consuming page content space. This keeps the UI clean, professional, and consistent across all pages. Instead of placing the page title inside the page body:         ✅ Fetch the current page title dynamically         ✅ Display it right after the APEX logo         ✅ Do it globally, so it works for every page All of this is achieved using:         ✅ Global Page (Page 0)         ✅ One Dynamic Action         ✅ PL/SQL + JavaScript Simple, effective, and reusable. 1️⃣ Create a Global Page Item On Page 0 (Global Page), create a hidden item:      P0_PAGE_TITLE This item wi...
Post a Comment
Read more

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 ...
Post a Comment
Read more