Skip to Content
author's profile photo Former Member
Former Member

adding and deleting columns, database obj not consistent w data dictionary

One of our developers has made two consecutive changes to an existing Z-table (ZREMAN).

First he deleted 2 columns: the last one and the last one but two; he added 4 columns (at the end). He imported all this in QA.

Next he deleted the 4 new columns and he restored the two deleted columns. He then imported this in QA.

We now have a problem with this table in the QA-system.

old version (DEVK960237 05.09.2008 13:10:45 RXBAIR) ends on columns:

REPID

BOCOST

LOCOST

BNCOST

LNCOST

first modification of this week (DEVK961680 02.12.2008 15:15:05 RXBAIR) - table now ends on columns:

REPID

BOCOST

BNCOST

ZGARAW

ZGAMAN

ZGAOVER

ZGASUB

second modification of this week (DEVK961716 03.12.2008 14:52:46 RXBAIR) - table now ends on columns:

REPID

BOCOST

LOCOST

BNCOST

LNCOST

In other words, this attempts to restore the old structure.

Import of this last request ended with a warning, but succeeded in updating the SAP data dictionary.

However, there are inconsistencies with the "database object" (as seen in the DB2/400 data dictionary, I suppose).

The current "database object" ends on the following columns:

REPID 31 GRAPHIC 40 X UX'0020'

BOCOST 32 DECIMAL 11 2 X 0

LOCOST 33 DECIMAL 11 2 X 0

BNCOST 34 DECIMAL 11 2 X 0

LNCOST 35 DECIMAL 11 2 X 0

ZGARAW 36 DECIMAL 11 2 X 0

ZGAMAN 37 DECIMAL 11 2 X 0

ZGAOVER 38 DECIMAL 11 2 X 0

ZGASUB 39 DECIMAL 11 2 X 0

I have tried rebuilding the table (database utility SE14). The rebuild has succeeded (warning - same warning as the CTS request), but it has not had any effect.

Every ABAP program that attempts to access this table end in a short-dump.

The short-dump itself says:

Database error text........: "Object ZREMAN in R3QAPDATA type *FILE has a

pending change. MSGID= Job=969096/QAP02/WP04"

Internal call code.........: "[RSQL/OPEN/ZREMAN ]"

Please check the entries in the system log (Transaction SM21).

The SysLog says:

Database error -910 at PRE access to table ZREMAN

> Object ZREMAN in R3QAPDATA type *FILE has a pending change.

> MSGID= Job=969096/QAP02/WP04

Run-time error "DBIF_RSQL_SQL_ERROR" occurred

> Short dump "081204 023801 USDUR01_ QAP_02 " generated

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on Dec 04, 2008 at 10:17 AM

    Dear Peter,

    What does the consistency check in SE14 tells you? (there are 2 checks, do them both)

    If still in error, can you loose / recover easyly the data in this table?

    If so, save the object on OS, then delete and create this table in SE14.

    This allways creates a consistent table.

    You could then try to copy the data from the backup using sql commands in STRSQL

    Could also be that the table is now correct, but becuae of old SQL package sap still tries to access some part of the old table. Delete the SQL packages while sap is off-line.

    Good luck,

    Paul Hoogendoorn

    Add a comment
    10|10000 characters needed characters exceeded

    • Former Member

      Thank you for your reply.

      The check on "database object" fails.

      The check on "runtime object" succeeds.

      When I look at the database object (in SE14) I see all columns: those that have been deleted and restored and also those that have been added and deleted.

  • author's profile photo Former Member
    Former Member
    Posted on Dec 04, 2008 at 10:36 AM

    By the way: "force conversion" (in SE14) fails, because the database object is inconsistent.

    Add a comment
    10|10000 characters needed characters exceeded

  • author's profile photo Former Member
    Former Member
    Posted on Dec 11, 2008 at 10:39 AM

    As far as I can see, the situation evolved as follows:

    1. Last week, in the QA-system, the database object disagreed with the runtime object and the dictionary object.

    2. After an IPL, the database object and the runtime object agreed - this made SE16 (and SE16N) possible - but they disagreed with the dictionary object.

    3. We then used the technique described in note 1248769. This means "Reconstruct". As a result, there was a complete internal consistency within the QA-system. However, the QA-system disagreed with DEV and the Production system.

    The remainder is "normal" procedure:

    4. Adjusted the DEV system to match the definition in the QA-system. This created a transport request. DEV now agreed with the QA-system (but not with the Prod system).

    5. Imported this in the QA-system. DEV still agreed with the QA-system (of course)(but not with the Prod system).

    6. Imported this in Production.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.