[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5019.0. "IMPORT, COMPUTED BY Fields Returning Errors" by M5::BLEHLBAC (RDB: 34% better than real life) Tue Feb 11 1997 10:50

Hi,

  IMPORT of COMPUTED BY field returning errors.

  This is in reference to Note 2881 (rdb_60).

  Does anyone know if the problem was entered in to the BUG database
and/or if a resolution/workaround was ever determined??

  I have a customer with a similar problem and is looking for a possible
workaround.  The customer appears to be getting errors on both the import
of a table, which contains a computed by field, as well as views.  The
computed by field is:

-----
ALERTS                          INTEGER
 Computed:       by
                         ( select count(*) from Alerts
                             where Alerts.Offender = Offenders.Offender )
-----

  "Alerts" is a also table name.

Errors received are:

-----
%SQL-E-NOCMPBYRES, computed field ALERTS in relation OFFENDERS not imported
%RDB-E-NO_META_UPDATE, metadata update failed
-RDB-E-OBSOLETE_METADA, request references metadata objects that no longer
exist
-RDMS-F-TABNOTDEF, relation SEPARATEVIEW is not defined in database
-----

  Philippe Delobel, who spr'd the problem on the DEC side (note 2881.6),
does not know if was entered (BUGged) on the Oracle side.

  I can post additional information that I've received from my customer,
the complete log contains many similar errors and is quite long (about
2000 lines).

  Any help would be greatly appreciated.

                                      Thanks,  Barry
T.RTitleUserPersonal
Name		DateLines
5019.1NOVA::SMITHIDon't understate or underestimate Rdb!Tue Feb 11 1997 11:2512
Well this might be a known restriction.  have them DROP the computed by column
before the EXPORT and then manually define it after the IMPORT succeeds.

The problem is that the table reference by the computed by column may not have
been imported yet.  Look at the IMPORT log and see if ALERTS has been
imported.

IMPORT performs its work in a serial nature, trying to reproduce the metadata
changes in the correct chronological order, but because of ALTER TABLE this is
not always possible.

Ian
5019.2BugNo:452435M5::BLEHLBACRDB: 34% better than real lifeWed Feb 12 1997 15:192
The customer requested that the problem be elevated.  Entered BugNo:452435.
5019.3NOVA::SMITHIDon't understate or underestimate Rdb!Wed Feb 12 1997 18:146
~Well this might be a known restriction.  have them DROP the computed by column
~before the EXPORT and then manually define it after the IMPORT succeeds.

Did they try this?

Ian
5019.4workarounds have not been attemptedM5::BLEHLBACRDB: 34% better than real lifeWed Feb 19 1997 10:0320
>>    <<< Note 5019.3 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>
>>
>>~Well this might be a known restriction.  have them DROP the computed by column
>>~before the EXPORT and then manually define it after the IMPORT succeeds.
>>
>>Did they try this?
>>
>>Ian

Ian,

Sorry for the delay in answering you.

I talked with the customer about your question.

The customer has not tried a workaround yet.  But, he is concerned that if any
of the triggers or stored procedures reference one or more of the computed by
columns the import may fail (if the columns are dropped).

                               Barry
5019.5NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Wed Feb 19 1997 11:018
Well I have to say that they will have to find a workaround.  No shipping
version will be modified to include the type of changes that would be required
to support this database setup.

They should abandon EXPORT and IMPORT and build their own RMU/EXTRACT scripts
and use RMU/UNLOAD and RMU/LOAD.

Ian
5019.6thanksM5::BLEHLBACRDB: 34% better than real lifeWed Feb 19 1997 13:256
    <<< Note 5019.5 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>

>>They should abandon EXPORT and IMPORT and build their own RMU/EXTRACT scripts
>>and use RMU/UNLOAD and RMU/LOAD.

  OK .... thanks for the follow-up.   Barry
5019.7NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Wed Feb 19 1997 14:086
Well I have now had a nice Sushi lunch... and am in a better state of mind. So
have them submit a bug report, I might have a way we can fix this.  I'd like
to have an EXPORT version of their database (please have them use the NODATA
option), or a script such as shown previously.

Ian
5019.8thanks, againM5::BLEHLBACRDB: 34% better than real lifeWed Feb 19 1997 19:1910
    <<< Note 5019.7 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>

Well I have now had a nice Sushi lunch... and am in a better state of mind. So
have them submit a bug report, I might have a way we can fix this.  I'd like
to have an EXPORT version of their database (please have them use the NODATA
option), or a script such as shown previously.

Ian

----> OK .....  will do.  Thanks !!  Barry
5019.9M5::LWILCOXChocolate in January!!Thu Feb 20 1997 08:488
  <<< Note 5019.7 by NOVA::SMITHI "Don't understate or underestimate Rdb!" >>>
 
>>:Well I have now had a nice Sushi lunch... and am in a better state of mind. So

Attention Technical Support, THIS is the way to Ian's heart!!  Please see
your manager for dry ice, Sushi, and shipping instructions.

:-). Liz
5019.10Anyone for...OOTOOL::HIGGSSQL is a camel in disguiseThu Feb 20 1997 18:533
...chocolate-covered sushi?

8^)~