You’re right that “0 rows” by itself shouldn’t cause ORA‑01013. That error almost always means “the server aborted the work” (usually due to timeout, connection drop, or session kill), not a logical problem with the query result.

Given your description and the forum cases you shared, here’s how I’d look at it from an OutSystems + Oracle 19c perspective.

1. Is the “0 rows” situation related?

Almost certainly only indirectly, if at all.

Oracle does not cancel a query because a table is empty. The query optimizer might even execute faster with an empty table. So:

• If this timer normally runs fine;
• This run had a shorter duration than usual;
• The only difference is that the main table had 0 records;

Then the “0 rows” condition is likely a red herring. ORA‑01013 was more probably triggered by:

• a timeout in OutSystems or Oracle, or
• a network / session problem at the exact moment the query was running.

The examples you provided support this: ORA‑01013 is consistently reported as a timeout or blocking/locking symptom, not as a data-content symptom. ORA-01013: user requested cancel of current operation

2. Common real‑world causes in OutSystems + Oracle

Here are the most typical causes I’ve seen (and that appear in your referenced topics):

1. Execution timeout (application or infrastructure)

   • OutSystems timers have a configured timeout (platform setting). If the timer execution, or a specific query inside it, takes longer than that, the scheduler can abort it.
   • For web / reactive flows there are also default timeouts (e.g. 10s) that can manifest as ORA‑01013 on Oracle. CreateOrUpdate entity action times out

2. Database locking / transaction issues

   • Some other process (timer, BPT, or long-running transaction) might hold locks on the same Oracle objects your Advanced Query is touching.
   • If your timer is:
     • Updating/inserting into a table while another process holds a lock, or
     • Reading with locking hints, or
     • Running in a separate transaction while another service action hasn’t committed yet,
       Oracle may block your query until it hits some global or connection timeout, resulting in ORA‑01013.
   • In one of your examples the fix was to commit before calling a service action, so the second transaction didn’t get blocked by uncommitted changes. CreateOrUpdate entity action times out

3. Network / connection drops

   • If the app server loses connectivity to Oracle mid-execution (firewall reset, load balancer, TCP idle timeout, etc.), .NET / OutSystems can translate that into ORA‑01013 because Oracle sees the session as abruptly terminated.

4. Scheduler / timer infrastructure errors

   • In the timer case you pasted (underlying connection was closed), the root cause was processing too much data per run; the solution was to chunk the work and re-schedule the timer for the remaining data. Timer being aborted - The underlying connection was closed: An unexpected error occur
   • Even though your current run had less data, something similar (connection closed by host) might have happened on the infrastructure side.

5. Oracle Resource Manager / maintenance operations

   • DBAs might configure Resource Manager to automatically abort or downgrade sessions that exceed certain limits (CPU, I/O, elapsed time).
   • Maintenance jobs (like statistics gathering, index rebuilds, or backup/restore operations) could also kill sessions, although that is less common.

3. Targeted checks you can do

Because you’re using an Advanced Query inside a Timer, I’d follow this checklist:

3.1. Collect exact context from Service Center

• Go to Service Center → Monitoring → Timers and:

  • Confirm Execution Start / End time.
  • Check if the log mentions “request duration = X secs” or similar (like the example you included), which may indicate a timer timeout.
  • See if there were automatic retries (OutSystems will retry failed timers).

• Check General Logs / Error Logs around that time:

  • Look for “connection was closed”, “request timeout”, “thread aborted”, or similar messages.

3.2. Ask DBA for Oracle-side info

Ask your DBA to check around the timestamp of the error:

• alert.log and listener logs for:
  • session killed, resource manager actions, network disconnects.
• Any Resource Manager rules active (e.g. maximum elapsed time per query).
• Any scheduled maintenance job or backup/restore around that time.

Also: see if Oracle’s v$session / v$session_event / dba_audit_trail captured your session being terminated.

3.3. Review the Advanced Query itself

Even if the main table is empty, check for:

• Joins to other tables that might be large or have missing indexes.
• Functions or expressions in WHERE clauses that could disable index usage.
• Hints or locking clauses (e.g. FOR UPDATE) that could cause blocking.
• WITH (NOLOCK) is not valid in Oracle, but ensure no custom hints break things.

You can get the SQL from the Advanced Query and ask the DBA to:

• Run it manually in SQL*Plus/SQL Developer at the same time of day,
• Capture its execution plan and runtime,
• Check if there’s any wait event (locks, I/O, etc.) associated with it.

3.4. Check for parallel timers / processes

Verify if:

• This timer might run overlapping instances (e.g., previous run still working when the next one starts).
• Any BPT processes, other timers, or integrations are touching the same tables (either source or target).
• Any Service Actions called from the timer are uncommitted or long-running, causing cross-transaction locking (as in the CreateOrUpdate example). CreateOrUpdate entity action times out

3.5. Timer and Platform configuration

With your platform admin:

• Confirm Timer execution timeout in Configuration Tool / factory settings:
  • If the timer is close to that time, an occasional spike (network, DB load) can push it over the limit.
• Confirm DB connection timeout and pool settings.

4. Practical mitigations / tests

To narrow it down and avoid surprises:

1. Log more context in the Timer

   • Log:
     • Input parameters.
     • Actual SQL parameter values.
     • Elapsed time before/after critical queries.
   • This helps confirm if the failure is consistently after a specific Advanced Query.

2. Run a “no-op” version of the Timer

   • Temporarily replace the Advanced Query with a simple “SELECT 1 FROM DUAL” or a minimal query.
   • If ORA‑01013 still occurs, you’re very likely dealing with connection/timer timeout or infrastructure issues rather than the query logic.

3. Chunk the work (if not already)
   Even if this specific run had fewer records:

   • Implement pagination or “process N records per run” pattern.
   • Use a controlling attribute (e.g., last processed ID/date) and reschedule the timer until everything is processed.
     This is a best practice and helps prevent long-running transactions that are more susceptible to timeouts. Timer being aborted - The underlying connection was closed: An unexpected error occur

4. Ensure proper commits

   • If the timer calls Service Actions or other actions that may encapsulate their own transactions, consider:
     • Adding explicit CommitTransaction when appropriate (careful with consistency).
     • Avoiding long-running uncommitted updates before calling external logic.

5. Direct answers to your specific questions

Could the empty main source table be related?

Not directly. Oracle will not cancel a query because the main table has 0 rows. The empty table likely just coincided with another issue (timeout, session kill, or network problem) that caused ORA‑01013.

Have others seen ORA‑01013 in similar conditions?

Yes. In OutSystems environments, ORA‑01013 is commonly reported when:

• Aggregates or Advanced Queries are too heavy or poorly filtered (timeouts) ORA-01013: user requested cancel of current operation
• Create/Update actions and Service Actions conflict due to transaction/locking issues CreateOrUpdate entity action times out
• Timers process large datasets / binaries and hit timeouts or connection issues Timer being aborted - The underlying connection was closed: An unexpected error occur

Are there known automatic causes (session termination, query timeout, etc.)?

Yes, all of these are plausible:

• OutSystems timer timeout.
• DB connection timeout (application server side).
• Oracle Resource Manager limits.
• Network / firewall / LB closing idle or long-lived connections.
• DBA killing sessions (manual or via jobs).
• Locked resources causing the engine to abort the call after some time.

If you can share (internally) the approximate duration when it fails, timer timeout configuration, and confirmation from the DBA whether your session was killed, you’ll probably pinpoint whether this is a simple timeout, a locking issue, or a network/session closure.