Error From pin_rate_change In A Multi-DB Environment (Doc ID 1088815.1)

Last updated on SEPTEMBER 19, 2016

Applies to:

Oracle Communications Billing and Revenue Management - Version 7.3.1.0.0 to 7.3.1.0.1 [Release 7.3.1]
Information in this document applies to any platform.
Checked for Relevance on 21th May 2013

Symptoms

In a multi-DB environment, the price is changed, BRM create a /rate_change object on the primary database. After snapshot replication, the object is present on the secondary database.

Launched the pin_rate_change, connecting to a CM -> DM on the secondary database. Getting error because it wants to update the status of the /rate_change on the secondary database and it's not possible because it is a view.

See the dm_oracle message :

E Sun May 23 13:13:47 2010 devbrm dm:8666 dm_subr.c(117):2637 1:devbrm:<no_name>:12966:1:5:1263826889:4
ORACLE error: do_sql_update: PINStmtExecute: code 1732, op 0
=ORA-01732: data manipulation operation not legal on this view
E Sun May 23 13:13:47 2010 devbrm dm:8666 dm_ops.c(177):4010 1:devbrm:<no_name>:12966:1:5:1263826889:4
OP_WFLDS do_sql_update "update rate_change_t set poid_rev = poid_rev + 1, mod_t = :mod_t, status=:status where poid_id0 = :poid_id0", x=1, id 7494525
E Sun May 23 13:13:47 2010 devbrm dm:8666 dm_back.c(27):1420 1:devbrm:<no_name>:12966:1:5:1263826889:4
DMbe #3: process_op: op 5, err 43


Which type of CM the pin_rate change have to be connected ?

Since pin_rate_change does modify/update the /rate_change object and since the actual /rate_change object is in the primary database, the pin_rate_chance application should also be run against the primary database. This is not just for pin_rate change, but any application that reads and updates an object should connect to the DB where the object actually resides.

But, after some internal analysis, a problem was found for pin_rate_change in a multi-DB environment. If the /rate_change object is in the primary DB then if you running pin_rate_change might not pick up the /purchased_products for accounts in the secondary DBs. Thi sis because the search is doing a PCM_OP_SEARCH instead of a PCM_OP_GLOBAL_SEARCH.

As a conformation, only the primary account are searched (but there is no such account in that DB).

Cause

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