Skip to Main Content

Analytics Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Business Rule _ on dynamic calc members

661221Jun 14 2010 — edited Jun 14 2010
Hi

I am getting the following error when i validate a BR.

Total = Account1 * Account2

'Error:Calculation is not allowed for virtual member [TOTAL] in the Calc script.

TOTAL is a dynamic calc member . should i cahnge TOTAL to store data. Cant we define Calcs on dynamic calc members.
This post has been answered by JohnGoodwin on Jun 14 2010
Jump to Answer

Comments

L-MachineGun
Have you tried to set it to NULL?:
UPDATE badtable
   SET badvar = NULL
 WHERE LENGTH (badvar) = -1;
:p
PS: create a copy of the table first...
Guess2
I was clear when I stated we are finding this in multiple tables and we do not even know what column is involved. We failed in one table that is 40 gbs and we do not even know what field it is in. I need to scan the whole database. I also do not know if all of the bad data has length = -1. I said that up front.

Can the character set scanner help with this or something similiar to that?
I am able to narrow it down to 1 field in a record.
I really just need to find the bad data and delete it.
sound like a contradiction - you are able, and you need ?

0. backup DB
1. try $OH/bin/dbv utility to find bad blocks.
2. try OS or 3-rd party tools to check filesystem and HDD for corruption. If HDD is corrupted - replace it. If FS is corrupted - fix it.
3. By block found in #1 you can find objects and rows. Not all rows and columns may be corrupted in the block. Find them all and present to data owner (business) to decide - delete or replace bad numbers with 0, or try to restore old good backup into a separate DB and copy these data from there.
unknown-7404
>
I really just need to find the bad data and delete it.
>
I have seen a problem like this one time in 20 years. Data in one column in a couple of tables would either 'disappear' or give weird results.

We finally tracked the cause of that problem to be a change Oracle made to the internal storage format between incremental releases. There was a bug that caused the internal format to not get converted properly to the new format in all cases.

Then when the data was accessed on the next Oracle major release version the bad format would cause data to either disappear or act weird. Have you performed any release updates lately? Or moved data from one Oracle version to another?

For that problem we were able to identify the bad data by examining the first byte of the dump results for the column.
Have no idea if your problem is similar but you show
MYRAWTOHEX           MYDUMP                                     MYLENGTH
-------------------- ---------------------------------------- ----------
C00000               Typ=2 Len=3: 192,0,0                             -1
The leading 'C0' hex is the '192' decimal shown in the dump

For our problem the good data might have had '197' in the internal format and the bad data '192'. NOTE - I don't remember the actual hex or decimal values for our problem but only that the good data all had the same value and all of the bad data had a different value - every row in the table should have the same value.

So one query you might try for your test case where you know you have at least one bad record is to do a dump of the column and see if there is any variation in the first byte of the internal format.

Using the above sample you would dump every row and look for anything other than 'C0'/192 - If you find more than one value that is a good candidate for the problem data.

You should try to keep a backup of the BAD table and data to provide Oracle support if they want it.
1 - 4
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jul 12 2010
Added on Jun 14 2010
2 comments
2,010 views