Posted: 18 Feb 2016 18:13 EST Last activity: 6 Apr 2018 19:26 EDT
ML Update - 7.1.9 to 7.2 - Failed with SQL Loader Exception
We are getting below exception, while updating Pega 7.1.9 to 7.2 using MS SQL Server during the update step. Please note we are using Out of Place Split Schema Update Approach in our environment.
When I analyzed I found that there are around 40 tables where we are trying to add a new column "pzTenantID" as Not Null. As there are rows in these tables system is not allowing to alter the tables with out giving a default value.
Update Software has provided an additional script file to be run for one of the table to add the pzTenantID as a Not Null Column with a default value of "Shared".
Did any one faced such issue earlier? Do we know whether we would really need pzTenantID as Not Null Column in all the 40+ tables? If so, I am planning to add the same default value of Shared in all the impacted tables and proceed with update.
Do you see any issues with this approach? Please share your thoughts.
com.microsoft.sqlserver.jdbc.SQLServerException: ALTER TABLE only allows columns to be added that can contain nulls, or have a DEFAULT definition specified, or the column being added is an identity or timestamp column, or alternatively if none of the previous conditions are satisfied the table must be empty to allow addition of this column. Column 'pzTenantId' cannot be added to non-empty table 'pr_index_circumstance_def' because it does not satisfy these conditions.
2016-02-18 21:31:52,317 ( SQLLoader) WARNING - Statement: ALTER TABLE pegaRules.pr_index_circumstance_def ADD pzTenantId VARCHAR(255) NOT NULL
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
As per the 7.2 Update guide I could see that the scripts provided in the AdditionalUpgradeScripts folder is only for Multitenant system. Execution of that script results in the new column pzTenantID in PR_DATA_ADMIN_PRODUCT table.
We observed that executing the script for singe tenant system has caused the issue.