on 12-04-2008 10:07 AM
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
By the way: "force conversion" (in SE14) fails, because the database object is inconsistent.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
87 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.