Table inconsistent

[Former Member]

Hi all,

We added 2 fields to a structure append of table EQUI.

In our DEV system, everything works fine.

We transported to PRO system. And it is not possible to activate it.

So i tried to delete these 2 fields and transport it once again.

Error when transporting :

Request: Convert Table EQUI (DDIC/27.05.09/09:59)
Database object for table EQUI is checked
Database object for table EQUI is inconsistent
Request for EQUI could not be executed

When converting with se14 :

Database object for table EQUI is inconsistent
Message no. GT264

Diagnosis
Inconsistencies between the database object and the runtime object of the table were found when you checked the database object for the table to be converted. You therefore cannot correctly access the database table. You cannot convert the table in this status.

Procedure
Using Transaction SE11 (Extras->Database object-> Check) determine the type of inconsistency and correct it. Then activate the table again and execute the conversion.

And Comparison in SE11 :

Database object for EQUI is inconsistent: (Fields,Secondary indexes)   


  Fields: Inconsistent with the runtime object   


Runtime Object Database Position Data Type Length Decimals Not null Default 
ZZIB_MODIFS ZZIB_MODIFS does not exist 165 NUMBER 10   U 0 
ZZIB_MANQUES ZZIB_MANQUES does not exist 166 NUMBER 10   U 0 

Anybody has an idea?

Thank you.

Olivier.

[Former Member]

Hi

Sorry

Try to insert the missing fields again, then active the table and if the activation fails run the database utility

Max

[Former Member]

HI,

Did you adjust the database table first time via SE14 after you made changes in Development before transporting to Production?

It seems that now the runtime object and database object is not identical.

Check the structure of both via the meunu options in SE11.

Once again try to add those new fields and try adjusting it once again via SE14.

Regards,

Ankur Parab

[Former Member]

No i didn't adjust the database table first time via SE14. Since the job who was transporting the change was kind of blocked ( in stms, I still see a little truck in front of that first transport).

And i already tried to add these fields again in DEV and than tranport in PROD but I get the same result.

Is there any way to remove these field from the runtime object? I think the fields are in the runtime objects but not in the database.

Max : What do you mean by "using the database utility"? Its a MAXDB database, the only external tool I have is "Database manager".

Thank you.

Olivier.

[Former Member]

HI,

Please note that you always have to adjust the database table via SE14 if you are adding new fields to it else this results in a discepancy between the runtime object and database object.

You will now have to add the fields once again to the structure in your development system and then adjust it via SE14.

After it is consistent then only send it to production system.

Regards,

Ankur Parab

[Former Member]

Hi

What do you mean by "using the database utility"? Trx SE14

But u need to insert the fields again, can u give more details for the error of transport?

Max

[Former Member]

Ok things have changed:

After re-adding the 2 fields :

Runtime objects check is consitent.

Database check is not consistent :

  Database object for EQUI is inconsistent: (Fields)   


  Fields: Inconsistent with the runtime object   


Runtime Object Database Position Data Type Length Decimals Not null Default 
ZZIB_MODIFS ZZIB_MODIFS does not exist 165 NUMBER 10   U 0 
ZZIB_MANQUES ZZIB_MANQUES does not exist 166 NUMBER 10   U 0 

The se14 adjustement runs successfully.

After the adjustement, the database check is still inconsistent.

And when i try to open the table with se16 => shortdump :

Runtime Errors         DBIF_RSQL_SQL_ERROR
Except.                CX_SY_OPEN_SQL_DB
Date and Time          27.05.2009 13:14:55



 Short text
     SQL error in the database when accessing a table.

[Former Member]

Hi,

In the database utitlity(SE14) try doing the 'Force Conversion' from the menu option and then once again 'Activate and Adjust Database'. Use the SAVE DATA radiobutton so as to prevent your data from losing.

Regards,

Ankur Parab

[Former Member]

When I force conversion, i get the following error.

           Request: Force conversion Table EQUI (DEVEL/27.05.09/13:38)
           Process: sapprod_3
           No customer or SAP include CI_EQUI exists
           Enhancement category 3 possible, but include or subty. not yet classified
           Test activation of Table EQUI successful
           No customer or SAP include CI_EQUI exists
           No customer or SAP include CI_EQUI exists
           Database object for table EQUI is checked
           *Database object for table EQUI is inconsistent*
           Request for EQUI could not be executed 

I assume that the 2 fields are in the table, I can see them in tx SE11 when displaying table EQUI.

Thank you,

Olivier.

[Former Member]

Hi,

What you can do is as follows:-

1. Delete the 2 fields.

2. Activate your table.

3. Check the runtime and databse structures

4. Adjust it using SE14.

5. Add the new fields.

6. Once again activate your table.

7. Check the runtime and database structures.

8. Once again adjust it via SE14.

I know this is cumbersome but the databse utility is the only tool to adjust your tables.

Regards,

Ankur Parab

[Former Member]

Hi

Have u insert the new fields in structure CI_EQUI or in EQUI?

Max

[Former Member]

I created a structure append named ZZIB attached to equi. That's where i add all my fields. I allready added 92 fields without any problems...

To Ankur :

I get the same result : database inconstent but runtime object consistent.

When I deleted the 2 fields (directly in PRO system) both database and runtime object where consistent.

I tried to adjust, and force adjust but no way.

I just find something strange : in se16 the select where the program short dump is :

SELECT * FROM EQUI                     "client specified
                 APPENDING TABLE IEQUI
                 UP TO RSEUMOD-TBMAXSEL ROWS BYPASSING BUFFER
   WHERE EQUNR IN I1.

But I have a select in a program that I made where the select is working :

DATA t_data TYPE STANDARD TABLE OF zequi.

select  *
       into CORRESPONDING FIELDS OF TABLE t_data
       from equi
        where  sernr in s_sernr.

ZEQUI is a table without the 2 new fields, so it means that when i don't touch that 2 new fields, I have access to the table...

Thankyou.

Olivier.

[Former Member]

Double post sorry.

Edited by: Joskin Developpement on May 27, 2009 2:23 PM

[Former Member]

Something for Include structure CI_EQUI doesn't sound good.

I've adjusted EQUI table by SE14 and I can't see any warning about CI_EQUI in my log: it seems the system believes the include CI_EQUI exists but then it can't find it in dictionary.

Max

[Former Member]

Finally we decided to make a copy of the table, then delete it and recreate it with SE14.

Thanks to all for your help.

Olivier.