Known Issues and Notes

Silent Wrong SQL Results

When an SQL query completes without error, but the query results have incorrect or incomplete data, it is considered a silent wrong result. Because no error is raised, customers may not realize that the returned data is incorrect. The 2026.2 release contains the following known issues that can produce silent wrong results. These issues occur with limited query patterns involving rarely used features:

• Inconsistent or zero results with partitioned table and ID value in WHERE or ORDER BY clause

  This issue occurs with a query that uses a partitioned table and the WHERE or ORDER BY clauses uses the ID value. For example:

      SELECT * FROM demo.log WHERE ID = '1||9||5||87'
      SELECT * FROM demo.log ORDER BY ID
  

  

  For such a query, you may get inconsistent or zero results.

  This issue affects version 2026.1 through 2026.2.

• OR predicates on partitioned table may return incorrect results

  In the partitioned table feature, queries against key-partitioned tables that include an OR condition involving multiple partition key fields can return zero results. For example, on a table that is key-partitioned on fields f1 and f2, queries like the following can return no results, even when such rows do exist:

  SELECT * FROM demo.t WHERE (f1=1) OR (f2>8)
  

  

  This issue affects version 2026.1 through 2026.2.

Stored Procedures Do Not Support Common Table Expressions (CTEs)

InterSystems SQL supports both stored procedures and Common Table Expressions (CTEs). However, attempting to create a stored procedure that contains a CTE causes an error that prevents the system from creating the stored procedure. For example, the following example demonstrates a stored procedure that raises and error that prevents its creation:

CREATE PROCEDURE test.sp_test_cte(in inpOwner VARCHAR(128))
   BEGIN
   WITH cte1 AS (SELETE * FROM INFORMATION_SCHEMA.VIEWS)
   SELECT * FROM cte1 WHERE cte1.owner = 'jsmith'
   ;
   END

Partitioned Table Conversion Failures If Partition Key Field Is Not Lowercase

With the experimental table partitioning feature, you can convert an existing nonpartitioned table into a key-partitioned table. However, such a conversion fails if the partition key was created on a field whose name contains uppercase letters. There are no adverse effects on the table when the conversion fails.

Interoperability UI Performance Issues

InterSystems IRIS for Health 2025.2 introduced two changes that bring performance improvements to most use cases: smarter table statistics and enabling BiasQueriesAsOutlier by default. However, there are a small subset of queries that can be slower than before. The following components of the Interoperability user interface have queries that can fall into this subset:

• The Production UI

• The Message Viewer

• The Message Bank Message Viewer

• The Event Log Viewer

• The Business Rule Log Viewer

• The Production Monitor

These user interfaces can be slow when all three of the following conditions are true:

1. There are greater than 15 million entries in the Messages or Event Log table for the given namespace.

2. Some business components have significantly more activity than the others.

3. Activity on the business components is not evenly distributed over time (for example, if large batches of messages are processed in bulk or if some business components rarely see activity).

If these user interfaces have significantly slowed upon upgrade to this version, you can employ either of the following workarounds:

• Use the Purge Management Data feature to confirm that the Message and Event Log have fewer that 15 million entries. If so, purge old data as needed to bring the counts down. Then, purge cached queries in order for the change to take effect.

• In any namespace, manually set the following global:

  set ^%SYS("sql","sys","rtpc","planCostThreshold") = 10  
  

  

  This value is undefined by default. Then, purge cached queries in order for the change to take effect. If you wish to revert this behavior, kill the global subnode as follows:

  kill ^%SYS("sql","sys","rtpc","planCostThreshold")
  

  

Illegal Instruction Error on VMware When AVX-512 Is Expected but Is Not Exposed

If you are running InterSystems IRIS for Health inside a VMware vSphere® environment and the VM's CPU configuration does not properly expose the Intel® AVX-512 instruction set, processes may terminate with an illegal instruction error. This scenario occurs when clusters are configured with Enhanced vMotion Compatibility (EVC) which makes all VMware ESX hosts on the cluster appear to the compiler as having the same CPU hardware. If a VM was originally provisioned on older hardware that lacked AVX-512 support but currently runs on an ESX host using hardware with AVX-512 instructions, InterSystems IRIS for Health will attempt to run AVX-512–optimized routines and crash. To resolve this, upgrading the hardware compatibility of the affected VMs and power cycling can allow them to pick up support for AVX-512. This issue affects the 2024.1.1 maintenance release and onwards.