Question
Accenture
IN
Last activity: 23 Aug 2018 6:50 EDT
Issue in running GenerateDDL Ant Script under Media File
Background: We are doing a Split Schema Upgrade from 6.2 to 7.1.8 for one of our client with Non Admin User (Normal User who have access to one schema at a time).
In the Rule Schema Upgrade Phrase we were supposed to go through the following steps
1) Run the GenerateDDL script with upgrade rule shema Parameters
2)Execute all the SQL Scripts that got generated in the path <path for PRPC media image>/schema/generated/oracledate due the GenerateDDL execution with a DBAdmin User with All privilege
Issue Happened
No SQL script got generated in <path for PRPC media image>/schema/generated/oracledate Path after execution of Generate DDL
Please help us out with idea how to resolve this
***Updated by moderator: Lochan to update platform capability***
Accepted Solution
Updated: 8 Aug 2018 5:02 EDT
PEG
GB
For the schema, it's should perform a delta between what you currently have and what it needs to change.
So if you've already generated the schema and applied those changes, then this delta will determine that no further changes will be needed, and apply no changes.
If you keep bypass.schema.changes=false I don't think anything should change in terms of the database structure, but it will spend some additional time checking this.
As for the other two settings, I'm afraid I'm not too sure whether it will simply try to regenerate and replace they already exists, and their "bypass" setting is set to false.
As such, unless someone says otherwise, I'd be inclined to set these back to "true" before proceeding with the upgrade itself.
PEG
GB
I'm not sure if I've understood your starting point.
Do you mean you already have a split schema in your pre-upgrade 6.2 environment?
Or are you previously running the migrate.sh script to move the rules tables to a new schema?
Also, what output do you see when you run generateddl.sh --action upgrade
Does this show any errors or any output at all?
Incidentally, I believe the script may try to clear up the previous run's files in /schema/generated/oracledate so if you have, say, another command line session currently in this directory then this may cause the cleanup to fail.
Accenture
IN
Hi Laurence
First of all thanks for your response
We are doing an in place upgrade in dev environment from 6.2 to 7.2.2. We are using the Run book for Non Admin User.
We have created a new blank schema and completed the rule Migration process successfully. This Rule Migration Process comprised of Editing MigrateSystems.Properties file. I am attaching the parameter format I used in this process. Next Executed Migrate.sh. Next Executing the SQL scripts got generated in OracleDate Folder by a databaseAdmin User. Next again we edited the MigrateSystems.property file with following parmeter[attached]Next we again executed the migrate.sh script
Upto this process was success ful and we entered in RuleShema Upgrade stage
In this step we were supposed to execute generateddl script. check the oracledate folder for generated sql and execute them using DAdmin User. But no sql script generated in oracledate folder although generatyeSQL got executed sucessfully
Please let me know what to do in this step
PEG
GB
The best I can think to do is try the same in one of my environments.
Can you confirm which precise version of 6.2 you are starting from (6.2SP1 / 6.2SP2)?
And also clarify whether this is going to 7.1.8 or 7.2.2?
Accenture
IN
Hi Lauren
Please find the details below
1) Current system 6.3 SP1
Upgraded to 7.2.2
I am also attaching the Non Admin User run book which we are following
PEG
GB
The plan looks well constructed.
I did go through the generation of the migrated rules (and applied the SQL manually).
After this I'd rerun the migrate script to move the rules to the new schema.
But after this when I try to generate the 7.2.2 upgrade rules schema with "generateddl --action upgrade" this is generating the file ./schema/generated/oracle/update/oracledate.sql
Are you able to redirect the call to generateddl something like: -
./generateddl.sh --action upgrade | tee -a generateddl_output.log
Accenture
IN
Hi Laurence
I am able to redirect the call to generateddl
./generateddl.sh --action upgrade | tee -a generateddl_output.log
Please find the attachment for the log. Also please find the command below
sh generatedddl.sh-action Upgrade--dbType oracledate--dbSchema PRPCRULES--outputDirectory /app/Pega7/schema/generated/oracledate/--mtSstem false--username PRPCRULES-- password xxxx--url "jdbc:oracle:thin:@// Proprietary information hidden:1234/DPEGADE1"--driverjar /app/tomcat/lib/ojdbc6.jar--driverClass oracle.jdbc.OracleDriver | tee -a generateddl_output.log
PEG
GB
Thanks for the output. This tells me a lot.
To be perfectly honest I've not seen one of these settings before (the last one). But it appears that you have the following 3 settings in your setupDatabase.properties file: -
bypass.pega.schema=true
bypass.udf.generation=true
bypass.trigger.control=true
In the setupDatabase.xl file it's setting the pypass.prDDL.generation.set to "true" if all 3 of the above are true. So with: -
Thanks for the output. This tells me a lot.
To be perfectly honest I've not seen one of these settings before (the last one). But it appears that you have the following 3 settings in your setupDatabase.properties file: -
bypass.pega.schema=true
bypass.udf.generation=true
bypass.trigger.control=true
In the setupDatabase.xl file it's setting the pypass.prDDL.generation.set to "true" if all 3 of the above are true. So with: -
Accenture
IN
Thanks Laurence. It has worked now. I have one more question to you. While executing the Upgrade Shellscript after this process we hve to maintain the following setup in SetUpDataBase Property file to skip DDL Generation again
bypass.pega.schema=true
bypass.udf.generation=true
bypass.trigger.control=true
Please confirm
Accepted Solution
Updated: 8 Aug 2018 5:02 EDT
PEG
GB
For the schema, it's should perform a delta between what you currently have and what it needs to change.
So if you've already generated the schema and applied those changes, then this delta will determine that no further changes will be needed, and apply no changes.
If you keep bypass.schema.changes=false I don't think anything should change in terms of the database structure, but it will spend some additional time checking this.
As for the other two settings, I'm afraid I'm not too sure whether it will simply try to regenerate and replace they already exists, and their "bypass" setting is set to false.
As such, unless someone says otherwise, I'd be inclined to set these back to "true" before proceeding with the upgrade itself.