cancel
Showing results for 
Search instead for 
Did you mean: 

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

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

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.

dorothea_stein
Participant
0 Kudos

Hi Peter,

does the error/inconsistency still persist?

If so, I assume that a database error could be the root cause: For the longest time, DDIC request to add and drop fields at the same time have been split up into two consecutive ALTER TABLE statements. It looks like the "ALTER TABLE ... ADD COLUMN..." statement has been executed successfully, while the second statement "ALTER TABLE ... DROP COLUMN..." received an SQL0910 due to a DB bug.

You could actually open a CSN ticket or a PMR with IBM for that, I think...

If the error persists, I'd recommend to apply note 1240025. That should draw both requests together into one single ALTER TABLE statements thus avoiding the SQL0910.

Then apply the technique mentioned in SAP note 1248769 like you did before.

Best regards,

Dorothea Rink

Former Member
0 Kudos

Thank you for your reply. The problem was solved as I described in my posting dd 11 Dec. 2008.

JanStallkamp
Employee
Employee
0 Kudos

Hi Peter.

Thanks a lot that you have given the solution you found to your issue. This will help people who search the forum looking for a similar question. To make it more obvious that the question has been answered I have marked it as assumed answered.

Best regards,

Jan Stallkamp

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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.