Skip to main content
Question

cdb files in 25R2 when the custom is not opting for zero down time

  • June 15, 2026
  • 1 reply
  • 44 views

RakeshChangeshpur
Sidekick (Partner)
Forum|alt.badge.img+10

Hi Community,

 

we have a customer who is in 25R2 and we have few customizations delivered already in 25R1 so now in 25R2 when we are uplifting those i included the prepare_table_for_ebr in the existing cdbs to convert the _TAB to RTB stuff in accordance with the 25R2 code compliance as the customer isnt opting for zero down time

 

Let me know if this is the correct approach or do we need to remove the cdbs  completely from the repository?

 

Regards,

Rakesh

1 reply

ashen_malaka_ranasinghe
Hero (Employee)
Forum|alt.badge.img+14

Hi ​@RakeshChangeshpur,

Your approach is partially correct but not fully aligned with 25R2 best practices.

Adding Database_SYS.Prepare_Table_For_EBR in existing CDBs is a valid step for converting _TAB to _RTB and making custom tables EBR-compliant. This is especially applicable for custom entities or tables created without model/storage support. So, for upliftment, what you’ve done is acceptable as an initial adjustment.

However, retaining CDBs as-is is not the recommended approach. In 25R2, table creation and structural logic should ideally be moved to .ddlsource files using declarative syntax, and the preparation tool mainly works on those. If your CDB contains direct SQL for table creation, indexes, or sequences, that logic should be migrated out of CDBs rather than maintained there.

In essence, to make your repository DC compatible the following has to be done:

  • Any .CDB files have to be deleted before the first sanity build in the RU studio or, if the first sanity build was already successful, have to be set to 0-byte.

  • Any columns, tables, indexes or sequences that have been introduced from modifications and that used to be created by a CDB file now have to be created from a ..ddlsource file that is associated with an appropriate model file so the first sanity build on future Release Updates can still function.

The .ddlsource file is like any other model related file (e.g. .plsql, .views, .storage, etc.) and has to be associated with an .entity, .utility or .enumeration model or, for changes like removing obsolete objects, with a .dbchange model. A .ddlsource file without an association to a model will be completely ignored by the build process. The file can be deployed directly from IFS Developer Studio by opening it and deploying it like any other model related file.

When replacing .cdb with .ddlsource files you still have to make sure the .ddlsource file can add any new tables, columns and indexes. If you do not do that you will encounter issues in future release updates on the first sanity build.

Reason: When applying a release update the first sanity build applies all code in the customer-solution repository onto a fresh core database image (so with all core code pre-installed but no modifications installed yet). Without the CDB and without appropriate content in the .ddlsource it will then not add your modification columns/tables and thus fail.

CDBs are not supported at all if you enable FNDNZD component. 

Please see the technical documentation under [https://docs.ifs.com/techdocs/25r2/060_development/027_base_server_dev/225_reduced_downtime_delivery/020_code_changes/020_uptime_changes/010_migrating_cdbs/#overview] which contains the steps to take with CDB files when enabling the FNDNZD component.