Customization Uplift Steps for 25R2 ?

I realize reading through all of it again that it may be that for “Normal” Customers (offline delivery i.e. not using Delivery Continuity) you might be able to keep using CDBs and that ddlsource files are only for Delivery Continuity customers?

If that’s the case, am I to consider the nzd_validator to be a “non fatal” error (just telling you you won’t be able to do Online Deliveries, but offline is still ok), and the only requirement is to uplift existing Custom Table entities to EBR by appending the Prepare_For_Ebr command at the end of the CDBs for them, such as this ?

(I understand the doc says you dont need to do this for any custom fields added to Core entities as these are already uplifted for EBR by default with the upgrade files)

Thank you very much ​@Trewon,

I’m currently trying an approach with the Prepare_Table_For_EBR command appended to the end of my CDBs like I explained above, and so far those errors seem to have disappeared from the build log, although I don’t disagree that maybe creating a dedicated upg file might be the way to go. (To be perfectly honest, up until this point I never had to customize any upg or deploy.ini files so I didn’t even know it was possible to add them to your own repo)

If that doesn’t work I might take up your very thoughtful offer of a quick teams call just to make sure I got everything right. I’ll report back with progress a bit later as it takes me around 6 hours from ordering the environment to the environment being provisioned and the error log (if the install failed) being available. Not sure if it taking this long is normal, but at least I’ve been getting the logs to help me work through my other Customization Uplifts so I’m not complaining.

​@SimonTestard / ​@Trewon  is there a way we can make the feedback loop shorter in testing the upgrades? So now it seems we can only make the changes, apply them to the topic environment and indeed wait till things finish building? 

Can we somehow test this by running this on some remote environment so we are not dependent on the topic environments? 

​@Trewon i am thinking of updating the deploy.ini as this needs to add the file to the customer repository and future release applies may needs to change the files due to impact which is kind of additional overhead in each release?

This is likely to be honest, this is why I don’t really like having to use custom deploy.ini and POST Scripts etc because it can be very useful in a pinch but then you kinda add overhead to yourself in having to keep them updated every release :(

Did you ever get by these errors? I’m not getting EBR errors now but all my CDB files are failing with the same error.

ERROR:File '/opt/ifs/build-home/source/{Component}/database/{component}.cdb' with .cdb extension is not supported for online deployment. Please remove or empty the file to proceed.

But I don’t think I’ve specified anything to state that online deployment should be occurring. As the documentation is confusing, misleading often, and sometimes just plain wrong, and Copilot is totally baffled by it’s lack of clarity, the only thing I can get out of anything is that to disable online deployment, 

fndnzd: false

needs to be specified in solutionset.yaml. That line is present in my solutionset.yaml, the one in the fndbas component at least, and yet, I get these errors.

if fndnzd is false, it shouldn't take as online as i understood per documentation. Is this during deployment or delivery creation ? 

This is occurring during the Order Topic Environment of Manage Release Update. If we have to modify all the cdb files we currently have to be delivery continuity compliant, then that’s what we have to do but I didn’t think this was going to be a requirement going into the update process.

​@HoustonHockyMon ​@wahelk​​ @SimonTestard  Did you guys find a solution for this? We are trying to create a topic environment to verify the update, but we get the same .cdb extension is not supported for online deployment error as well. fndnzd is false in our solutionset.yaml. I see that ​@Trewon said that we can ignore these errors, but they are the only ones I can find in the logs and the topic environment failed.

As a note, we haven’t merged the automation release update branch into the release-update branch yet to complete the “apply release update in solution repo” step yet, as I’m trying to validate the branch before merging.

I can confirm that I managed to do absolutely every upgrade with those errors being present which is not an issue if you’re not a delivery continuity customer.

There should be logs in the database deploy section rather than the codegen section that highlight any error the installer has faced.

​@SimonTestard ​@dritter  You can ignore errors in the _ifs_ant_generatedb.log and _nzd_validaor.log files if fndnzd is disabled. Download the log files from the failed topic environment creation and search for Error: and !!!ERROR in the files and you’ll uncover the root cause of the failure. If neither of those strings are present in your logs, there’s a rare but not so rare error in SU2 where the db installer crashes after successful code generation. If that’s your root cause, you’ll just need to kick off your topic environment again.

​@SimonTestard ​@HoustonHockyMon thank you, both! Based on what you shared, I found the actual (EBR change) issues causing the topic environment to fail and corrected them. Now just waiting for a baseline environment and final release-update topic environment to succeed before I order a sanity.

Thanks again,

Dylan

Sorry to bother you again, ​@SimonTestard and ​@HoustonHockyMon, but I wanted to see if you ran into this issue too. I got through ordering the baseline environment, topic environment, and sanity build successfully. However, when ordering the delivery environment, I got errors for each of my EBR updates in the cdb files. One error type is for creating the RTB tables and the other is for creating indexes. I think if I can get past these last couple of issues, I should be good to get the update into our use place for one of our test environments.

Table Example:

!!!Error deploying file pdmcon/xxxxxx.cdb at 09-MAR-26 05:16:14
!!!Error occurred while executing Plsql Block
BEGIN
   Database_SYS.Prepare_Table_For_EBR('x_TAB', TRUE);
END;


ORA-20112: Prepare_Table_For_EBR error: Table x_TAB cannot be renamed to x_RTB as that table already exists.

Index Example:

!!!Error deploying file pdmcon/xxxx.cdb at 09-MAR-26 05:16:14
!!!Error occurred while executing Plsql Block
DECLARE
   index_name_ VARCHAR2(30) := 'x_RK';
   table_name_ VARCHAR2(30) := 'x_RTB';
   columns_    Database_SYS.ColumnTabType;
BEGIN
   Database_SYS.Reset_Column_Table(columns_);
   Database_SYS.Set_Table_Column(columns_, 'ROWKEY');
   Database_SYS.Create_Constraint(table_name_, index_name_, columns_, 'U', 'IFSAPP_INDEX', NULL, TRUE, TRUE);
END;


ORA-20112: Create_Constraint: Constraint x_RK already exists for another table.

​

I also get​ a “name already in use” error in a .edv file that I’m guessing is created automatically:
 

!!!Error deploying file pdmcon/xxxxxx.edv at 09-MAR-26 05:16:14
!!!Error creating VIEW x_TAB
CREATE OR REPLACE EDITIONING VIEW x_TAB AS
SELECT
       engineering_part_no,
       engineering_rev,
       engineering_part_desc,
       assembly_site,
       manufacturing_site,
       lot_size,
       rowversion,
       rowkey
FROM   x_rtb

ORA-00955: name is already used by an existing object

Typical table creation in the cdb files looks like this. I’m not sure if this is right, but this is what I was able to order a successful topic branch with:
 

DECLARE
   table_name_ VARCHAR2(30) := 'x_RTB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table(columns_);
   Database_SYS.Set_Table_Column(columns_, 'FIELD_ONE', 'VARCHAR2(35)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'FIELD_TWO', 'VARCHAR2(35)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'LAST_FIELD', 'VARCHAR2(35)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'ROWVERSION', 'DATE', 'N');
   Database_SYS.Set_Table_Column(columns_, 'ROWKEY', 'VARCHAR2(50)', 'N', 'sys_guid()');
   Database_SYS.Create_Or_Replace_Table(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
END;




BEGIN
   Database_SYS.Prepare_Table_For_EBR('X_TAB', TRUE);
END;

Then the indexes are just created off the tables, but I think the real issue is just the tables/table names.

I appreciate any insight you can share!

Dylan

​@SimonTestard  ​@dritter Oh yeah...I definitely ran into those issues. Don’t know if I approached it correctly but it did seem to get me past this issue. I classified my cdb files into two categories: completely new tables. Those were addressed by appending the Database_SYS.Prepare_Table_For_EBR(table_name_); to the end of the table creation script. And modified tables. Those I looked at the .cre files that were generated for 25R2 and modified accordingly. So an example of each is given below. I’ve not successfully created an order delivery yet but it’s not IFS issues but some problems with my customer solution repository...I think.
 

DECLARE
   table_name_ VARCHAR2(34) := 'NEW_TABLE_TAB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table(columns_);
   Database_SYS.Set_Table_Column(columns_, 'COLUMN_1', 'VARCHAR2(20)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'COLUMN_2', 'NUMBER', 'N');
   Database_SYS.Create_Or_Replace_Table(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
   Database_SYS.Prepare_Table_For_EBR(table_name_);
END;
-- [END IFS COMPLETE BLOCK]
/
DECLARE 
   table_name_ VARCHAR2(34) := 'MODIFIED_TABLE_RTB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table#(columns_);
   Database_SYS.Set_Table_Column#(columns_, 'NEW_COLUMN', 'VARCHAR2(30)', 'Y');
   Database_SYS.Create_Or_Extend_Real_Table#(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
END;
-- [END IFS COMPLETE BLOCK]
/   

DECLARE
   table_name_ VARCHAR2(34) := 'NEW_TABLE_TAB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table(columns_);
   Database_SYS.Set_Table_Column(columns_, 'COLUMN_1', 'VARCHAR2(20)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'COLUMN_2', 'NUMBER', 'N');
   Database_SYS.Create_Or_Replace_Table(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
   Database_SYS.Prepare_Table_For_EBR(table_name_);
END;
-- [END IFS COMPLETE BLOCK]
/
DECLARE 
   table_name_ VARCHAR2(34) := 'MODIFIED_TABLE_RTB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table#(columns_);
   Database_SYS.Set_Table_Column#(columns_, 'NEW_COLUMN', 'VARCHAR2(30)', 'Y');
   Database_SYS.Create_Or_Extend_Real_Table#(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
END;
-- [END IFS COMPLETE BLOCK]
/   

Thanks for the info! Again, I had a successful topic environment and sanity build now with the 25R2 syntax (Create_Or_Extend_Real_Table#, Set_Table_Column#, etc), but a build delivery just finished, and unfortunately I still get the same “Table exists”, “index exists for another table”, and “view name already used by another object” errors. I think I’ll have to open a support ticket for the EBR changes at this point.

You’re at the same point I’ve been for over a week. There are two areas to check. First, review the _deploy.log for errors. Common issues include DML in CDB files, which must be moved to SQL files and referenced in deploy.ini, as well as dynamic dependencies where custom fields reference other components before those fields are created.

A second, unresolved issue involves references to renamed tables in the codebase. These appear in the database_cleanup folder within the _ebr_compliance.log. In my case, an entity was fully deployed (_tab, _api, _svc, and view) and then renamed without obsoleting the original. Despite multiple attempts to remove it, I’ve been unsuccessful. With a feedback loop of roughly half a day, progress has been slow.

I made a few changes and was finally able to successfully order a delivery environment (not to use place yet). I will be reviewing today and if everything looks good I will order a delivery to our use place overnight. If that works out, I’ll post some details here on what our final EBR changes looked like with our somewhat small number of modifications, though I have not prepped for delivery continuity at this point.

Thanks,

Dylan

Congrats! My order delivery succeeded for the first time last night also. Reviewing the error logs with a colleague last night and realized the table I was trying to get rid of was in the N/A component while the corresponding view, package, and package body were in the accrul component. It’s been a journey.

Thank you and congratulations to yourself! We have successfully pushed the changes to our use place/CFG environment. In the hopes that it helps someone else in the future, this is what our limited number of custom objects looked like in the cdb files (we did not prepare our code for delivery continuity at this time).

Custom Tables:

-- [IFS COMPLETE BLOCK DECLAREEND]
DECLARE
   table_name_ VARCHAR2(30) := 'XXXXX_TAB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table(columns_);
   Database_SYS.Set_Table_Column(columns_, 'FIELD_ONE', 'VARCHAR2(75)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'FIELD_TWO', 'VARCHAR2(5)', 'N');
   Database_SYS.Set_Table_Column(columns_, 'ROWVERSION', 'DATE', 'N');
   Database_SYS.Set_Table_Column(columns_, 'ROWKEY', 'VARCHAR2(50)', 'N', 'sys_guid()');
   Database_SYS.Create_Or_Replace_Table(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
   Database_SYS.Prepare_Table_For_EBR(table_name_);
END;
-- [END IFS COMPLETE BLOCK]
/

Indexes for Custom Tables:

-- [IFS COMPLETE BLOCK DECLAREEND]
DECLARE
   index_name_ VARCHAR2(30) := 'XXXXX_PK';
   table_name_ VARCHAR2(30) := 'XXXXX_RTB';
   columns_    Database_SYS.ColumnTabType;
BEGIN
   Database_SYS.Reset_Column_Table#(columns_);
   Database_SYS.Set_Table_Column#(columns_, 'PRIMARY_KEY');
   Database_SYS.Create_Constraint#(table_name_, index_name_, columns_, 'P', '&IFSAPP_INDEX', NULL, TRUE, TRUE);
END;
-- [END IFS COMPLETE BLOCK]
/

-- [IFS COMPLETE BLOCK DECLAREEND]
DECLARE
   index_name_ VARCHAR2(30) := 'XXXXX_RK';
   table_name_ VARCHAR2(30) := 'XXXXX_RTB';
   columns_    Database_SYS.ColumnTabType;
BEGIN
   Database_SYS.Reset_Column_Table#(columns_);
   Database_SYS.Set_Table_Column#(columns_, 'ROWKEY');
   Database_SYS.Create_Constraint#(table_name_, index_name_, columns_, 'U', '&IFSAPP_INDEX', NULL, TRUE, TRUE);
END;
-- [END IFS COMPLETE BLOCK]
/

Customizations made to IFS-defined Tables:

DECLARE
   table_name_ VARCHAR2(30) := 'IFS_TABLE_NAME_RTB';
   columns_    Database_SYS.ColumnTabType;
   column_     Database_SYS.ColRec;
BEGIN
   Database_SYS.Reset_Column_Table#(columns_);
   Database_SYS.Set_Table_Column#(columns_, 'CUSTOM_FIELD', 'NUMBER', 'Y');
   Database_SYS.Create_Or_Extend_Real_Table#(table_name_, columns_, '&IFSAPP_DATA', NULL, TRUE);
END;
/

RDF Files - Not sure if this will help, but we left the definition of the _RPT table, as that threw an error if we removed it when it was used in the Report_SYS.Define_Report_() method, but we commented out the declaration of the do_rs_ variable and removed the if-statement for when do_rs_ is true. If there is a secondary if(do_rs_) statement for updating the RPT table, that code was also removed.

Those are all of the customization types we had, but I hope this helps anyone else. Happy Friday!

Dylan

Hi Dylan,

thank you for explanation of what you have done to upgrade without Delivery continuity.

I have a question on this RTB table and indexes.

According to IFS  documentation, its enough to rename the tables using the prepare_table_for_EBR method which rename table to _RTB table  and created edition view  _TAB and reference the indexs and keys.

So do we need to change code of existing  index and constraints in cdb using # methods?

Best Regards,
Wasana

Depends on where you place the Database_SYS.Prepare_Table_For_EBR(table_name_); statement. If it’s the very last statement of the custom table script, that is after the index and constraint creation, the index and constraint creation will be like the pre-25R2 syntax. If it’s like Dylan and I have our code, the index and constraint creation will be like the 25R2 and post syntax.

​@HoustonHockyMon thank you very much. That clears my doubt.,