Upgrade from 8.4.0 to 8.4.2

Hi,

While running the upgrade.sh script, we are seeing the error
“[pega:getupgradefromversion] Failed to find current installed version of PRPC”.

We are using the 116826_Pega8.42.zip file to perform this upgrade. The database has a running version of 8.4.0 - the application was shutdown prior to running the upgrade script. The setupDatabase.properties file is updated with all the necessary Database information. The connectivity to the database is not an issue. Could you please help us to resolve this?

Thanks,
Hari

can you please share the complete upgrade logs?

Please find the upgrade logs attached. Hope you could take a look and advice.

cheers,
Hari

upgrade.txt (4.27 KB)

Check if you have a similar issue as this one: https://community.pega.com/support/support-articles/failed-find-current-installed-version-pega-upgrading-data. Check the pySetting column of the table .pr_data_admin_product to confirm. Not sure how you database gets into the state if that is the case.

You need to configure the pySetting column with correct code set version from pr_data_admin_product table

Thanks for the responses.
Our application is built on PEGA Customer Service 8.4 and is running on Red-hat Openshift 3.11. We are still seeing the same error even after the below update. Hence raised INC-147466.

UPDATE pega_rules.PR_DATA_ADMIN_PRODUCT SET pysetting='08-04-00'
WHERE PXOBJCLASS = 'Data-Admin-Product' 
AND PXPRODUCTNAME='PegaRULES Process Commander' 
AND PXINSNAME 
NOT LIKE '%CUSTOMER%';
COMMIT;

Steps - The application is shutdown first. The 8.4.2 files are downloaded to a different server (not the application server), extracted, and upgrade.sh script is run in this server.

Hi,

Are you running data only upgrade or is it full upgrade(both rules and data).

upgrade.sh --dataOnly=true or upgrade.sh

Regards,

Mritunjay

Hi Mritunjay,

We are running just “upgrade.sh” (please check the attached log file in my previous response). Also, I can see that the Oracle User mentioned in setupDatabase.properties has the required permissions because the upgrade runs fine when I use a DB which does not have the PEGA Customer Service 8.4.0 installed. The user permissions are similar across both the databases.

Thanks for the responses,

best regards,
Hari

you may also check whether The oracle user(mentioned in setupdatabase.properties) has been granted the DBA role or role that has all the necessary privileges to access the rules and data schemas.

I see that you have created INC-147466, so has the issue resolved?

you have tried few approach, so may you also try by setting the pysetting=‘8-4-0’ and check if it works.

just 8-4-0 not 08-04-00..

Have you also tried generated the DDL separately by running ./generateddl.sh --action upgrade , if yes then may you please let us know that whether you get the same error or does it work fine.

Have you downloaded 116826_Pega8.42.zip and extracted and then transferred to the server where you are running the upgrade, if yes then you may try placing/transfering the media116826_Pega8.42.zip to the server where you are running upgrade and unzip the media and then try to run the upgrade.

Yes, the issue got resolved after the DB user permissions were updated.

Sorry for the trouble.

Hi @HariR246 ,

Usually in Pega Platform Upgrade Guides , there is a section “General user permissions” under Preparing your Database , was this over looked or was there any specific permissions that was needed in addition to what is already mentioned ?

Thanks ,

Praveen (PJ)

A few differences I have found in our Tomcat context.xml configuration compared to what is prescribed in the Pega Platform upgrade document:
a. we use schema owners in the resources, instead of runtime users (pega_data, pega_admin).
b. we do not use datasourceAdmin configuration.
c. we do not have a pega_admin resource configured.

d. Also, in the DB, the pega_admin user is assigned the specific DB role (with all necessary privileges) only when there is a need. This is due to security compliance requirements.

Making the above configuration update (d) helped fix this issue with the upgrade.