Updating dynamic code in Thinkwise Platform version 2026.2 (AI-assisted)

Platform version 2026.2 introduces multi-RDBMS model support in the Software Factory. It is a significant step forward: for the first time, a single application model can target multiple database platforms simultaneously. We will utilize this feature ourselves to release IAM on Db2 and PostgreSQL in the near future. And customers can use this feature to deploy their application on different database platforms or to migrate to PostgreSQL for instance, for which Enrichments support is planned in a later release.

To make this possible, the Software Factory data model itself has changed significantly. A set of core tables now stores RDBMS-specific columns in a separate detail table, following a consistent _query naming pattern. This likely breaks some of your dynamic code.

If your model uses dynamic model code, SQL-assigned control procedures, or custom validations that reference any of these tables, you need to update those queries before generating your application on 2026.2. This post walks you through exactly what changed and how to fix it.

What changed

The tables below now each have a corresponding _query detail table. This detail table holds all columns that are RDBMS-specific. Any dynamic code that reads from or writes to one of these tables without accounting for the _query table will produce errors after the upgrade.

The following tables now have a _query detail table:

• col_data_sensitivity
• col
• cube_field
• data_migration_col
• data_set
• dom_input_constraint
• dom
• indx
• model_vrs_data_migration_col
• process_variable
• report_parmtr
• report_variant_parmtr
• tab_check_constraint
• tab_data_col
• tab_prefilter
• tab
• tab_variant
• task_parmtr
• task_variant_parmtr
• unit_test

The pattern is consistent: if you reference the tab table, the RDBMS-specific fields now live in tab_query. The same applies to every table in the list above.

How to update your queries

Start by generating your application immediately after upgrading to 2026.2. Generation errors are your first signal that dynamic code needs attention. Work through them systematically.

INSERT statements

For every INSERT into an affected table, add a second INSERT into the corresponding _query table. The _query table holds the RDBMS-specific fields, so both inserts are required.

Before upgrade

insert into tab (model_id, branch_id, tab_id, tab_description, view_from_clause)
values (@model_id, @branch_id, @tab_id, @tab_description, @ view_from_clause)

After upgrade

insert into tab (model_id, branch_id, tab_id, tab_description)
values (@model_id, @branch_id, @tab_id, @ tab_description)

insert into tab_query (model_id, branch_id, tab_id, view_from_clause)
values (@model_id, @branch_id, @tab_id, @ view_from_clause)

SELECT statements

If you select from an affected table and need RDBMS-specific fields, join the _query table. The example below uses tab, but the same pattern applies to every table in the list above.

Before upgrade

select t.*
from tab t
where t.model_id = @model_id
  and t.branch_id = @branch_id
  and t.tab_id = @tab_id

After upgrade

select t.*, tq.*
from tab t
join tab_query tq ON tq.model_id = t.model_id
 and tq.branch_id = t.branch_id
 and tq.tab_id = t.tab_id
where t.model_id = @model_id
  and t.branch_id = @branch_id
  and t.tab_id = @tab_id

If you only need non-RDBMS fields, the join is not required. Selects that already work without touching _query fields can remain unchanged.

UPDATE statements

What was one UPDATE statement now requires two: one for the main table and one for its _query counterpart.

Before upgrade

update tab
set tab_description = @tab_description
   ,view_from_clause = @view_from_clause
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

After upgrade

update tab
set tab_description = @tab_description
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

update tab_query
set view_from_clause = @view_from_clause
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

DELETE statements

DELETE statements follow the same two-statement pattern. Delete from the _query table first to avoid foreign key constraint violations.

Before upgrade

delete from tab
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

After upgrade

delete from tab_query
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

delete from tab
where model_id = @model_id
  and branch_id = @branch_id
  and tab_id = @tab_id

Control procedure SQL assignments

If a SQL-assigned control procedure returns an error, the missing field is most likely rdbms_type. When your model targets only one RDBMS, the Software Factory fills this field automatically. If it still produces errors, add it to your query explicitly. It does not cause any problems even when only one database platform is in use.

Use the following values when setting rdbms_type in your queries:

Custom validations

Review any custom validations that reference the affected tables. If they query RDBMS-specific fields, they need the same _query join treatment as your SELECT statements. Run your validations after fixing your dynamic code to confirm everything resolves cleanly.

Verify your work

Once you have updated all dynamic code and your application generates without errors, check that the dynamic code behaves correctly.

AI-assisted migration

Included with this post is a Claude skill that can make a solid first attempt at converting existing queries to the new 2026.2 data model structure. Output needs a review pass, but it gives you a head start. Simply provide the skill with the dynamic code and it will attempt to fix it.