Enforce Upgrade to v16 fails after rollback from successful upgrade.

Products

• Data Loss Prevention

Issue/Introduction

The customer successfully upgraded from v15.8 MP3 to v16.x but as part of a testing a rollback strategy they rollback the application and database to v15.8 MP3. Subsequent attempts to upgrade the product fail with the below error in the migrator log.

ERROR at line 1:
ORA-06510: PL/SQL: unhandled user-defined exception
ORA-06512: at "PROTECT.UPGRADER_CENTRAL", line 533
ORA-02291: integrity constraint (PROTECT.DATAIDENTIFIERPATTERN_FK1) violated -
parent key not found
ORA-06512: at "PROTECT.UPGRADER_CENTRAL", line 443
ORA-06512: at "PROTECT.UPGRADESCHEMA_DI_MIGRATION", line 1141
ORA-06512: at line 1063

No errors.
SP2-0584: EXIT variable ";BEGIN" was non-numeric
Usage: { EXIT | QUIT }    [ SUCCESS | FAILURE | WARNING | n |
       <variable> | :<bindvariable> ]  [ COMMIT | ROLLBACK ]

Resolution

This issue was caused because while the the database was rolled back, the customer didn't rollback the installer files specifically the files

D:\Program Files\Symantec\DataLossPrevention\EnforceServer\16.0.10000\Protect\Migrator\sql\add_di_regex_pattern.sql 
D:\Program Files\Symantec\DataLossPrevention\EnforceServer\16.0.10000\Protect\Migrator\sql\update_di_prepost_valid_characters.sql 

Not including the comments, both files are only supposed to have one executing line of code when they are laid down by the installer

set define off

When the migrator runs the DatabaseUpdate migration action, if the current version (based on the source install selected) is 15.8 then additional one-time only tasks are added to the action to convert the customer's DIs from legacy DIs to 16.x DIs. This is done by these tasks reading the customer's current DIs, executing a native application to convert their DIs and then appending the new definitions via SQL scripts into these two sql files which are then executed as part of the DatabaseUpdate migration action.

The last command of the append for both scripts is always 

EXIT;

When the migrator ran a second time, these sql files were already fully populated and the migrator appends to them as-is, thus the first "BEGIN" line of the append now resulted in the sql line 

EXIT;BEGIN

As this is not an allowed sql command, the new version of these sql scripts would now fail. 

After rolling back the database back to being a 15.8 schema, have the customer reset these files so that they once again only have the "set define off" command and comments with a final line feed to match what the files should look like before being populated by the migrator.