Wrong Created_t And Effective_t In Uniqueness Table When Using CMT To Migrate A Batch Of Accounts
Last updated on AUGUST 24, 2016
Applies to:Oracle Communications Billing and Revenue Management - Version 18.104.22.168.0 to 22.214.171.124.0 [Release 7.5.0]
Information in this document applies to any platform.
When using the Conversion Manager Tool (CMT) to migrate data on multi-schema setup, the date value EFFECTIVE_T of the UNIQUENESS_T table is initialized with the system date instead of the EFFECTIVE_T date value of the SERVICE_T table.
Indeed, CMT should populate the following UNIQUENESS_T dates according to this :
- UNIQUENESS_T.CREATED_T = system date
It represents the uniqueness object creation time and is therefore independent of the /service object creation time.
- UNIQUENESS_T.MOD_T = system date
It represents the uniqueness object modification time and is therefore independent of the /service object modification time.
- UNIQUENESS_T.EFFECTIVE_T = SERVICE_T.EFFECTIVE_T
The uniqueness object validity follows the service validity, when adapted, the uniqueness object is adapted too. This is why the effective_t of the uniqueness_t has to always follow the effective_t of the service_t.
Note that it does not follow the ACCOUNT_T table as the uniqueness is defined at the service level.
This problem only happens for a few accounts when several hundreds accounts are migrated as a batch on BRM 7.5 PS6.
This problem initially existed also when migrating a single account only, but was solved by <patch 18661151> on top of PS6, a port of the <patch 16708122> on top of PS4. This patch solved the situation when processing a single (or a small number of accounts), but the same problem remains in a slightly different condition : when processing a batch of a few hundreds accounts.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms