EBR materialized views and "No more data to read from socket" with DISTINCT / ORDER BY in source views

Hi all,

during a 25R1 to 25R2 upgrade, we converted several custom materialized views to the new declarative .views syntax to make them EBR compliant.

The generated `CREATE MATERIALIZED VIEW` statements use:

EVALUATE USING CURRENT EDITION

This is expected according to the .views documentation.

However, we found that materialized view creation can terminate the DB connection with:

No more data to read from socket

In our case, this happened when the source view dependency chain contained constructs such as:

• DISTINCT
• ORDER BY
• ROW_NUMBER() OVER (... ORDER BY ...)

After rewriting the affected source views to avoid these constructs, the materialized views were created successfully.

Examples of workarounds that helped:

• Replaced DISTINCT with GROUP BY
• Removed unnecessary ORDER BY clauses from view definitions
• Replaced ROW_NUMBER() OVER (... ORDER BY ...) logic with MAX / GROUP BY logic

We also found one deployment-order trap.

Calling Database_SYS.Prepare_M_V_For_EBR from a CDB file was problematic, because CDB runs before APV. This means the preparation can still use the old source view definitions, before the corrected views are deployed.

Since the materialized views are now defined declaratively in the .views file, we removed the explicit Prepare_M_V_For_EBR calls and let APV handle the materialized view creation.

Has anyone else seen similar behavior with EBR materialized views?

I am mainly interested in whether this is a known Oracle / IFS limitation and whether there are any recommended patterns or known SQL constructs to avoid when defining source views for EBR materialized views.

The most painful part is that the failure closes the DB connection, so the delivery continues with cascading errors such as:

• No database connection exists
• Closed Connection

instead of returning a clear SQL error.

(Reported to IFS in case CS0515494)