Changes to key fields of a Transparent Table and rearrange the fields

[avinash_s2]

Dear Community,

I have a delivered transparent DB table which has 5 key fields along with MANDT.

Can i now make the unique GUID (5th in position in SE11) as the only key with MANDT?

How to move this KEY up ? 🙂

Is delete and recreate the only option? hope it will not hamper the persisted records.

Cheers

Avinash

[satyapriyanka_vana]

Hi

Have u tried adjusting the table in SE14 after you made changes to the table?

Regards,

Priyanka.

[avinash_s2]

Hi,

Yes, Se14 tried. Got the error message in Se14 itself.

Thanks

Avinash

[raghug]

And what was the error message?

[avinash_s2]

"Key is already defined; field XXXX_XXXX cannot be in the key"

[Sandra_Rossi]

What is XXXX_XXXX ? Is it one of the fields of the primary key ? Which one ?

[avinash_s2]

YEs, it is one of the key fields.

[kiran_k8]

Avinash,

You replies are very terse.Reply in detail about before change and after change with

the list of fields.

the list of Primary keys & Index and

their sequence.

K.Kiran.

[raymond_giuseppi]

First create an index with your new keys list, define it as unique key, and check activation log.

If no problem you may change the primary key list (and remove the temporary index) but you will have to adjust the database table (SE14)

[kiran_k8]

Raymond,

Can we follow the same methodology for any case where we are changing the sequence of the Primary Keys or undoing the existing field as primary key.

If we follow this way,will it make sure that existing entries will be intact or do we need to take any extra measures to see that existing data is not corrupted.Thanks.

K.Kiran.

[Jelena]

I'm not Raymond but I believe that suggested technique helps to foresee some basic issues with the key fields themselves. But it's unlikely this can assure that the actual table adjustment in DB will go smoothly. There is no adjustment triggered for secondary indexes, AFAIK, so it won't tell you that.

It'd be a good idea to try the key change in a Sandbox system first to make sure the data is intact. As you correctly noted, one needs to be very careful here.

[RAF]

Please check the DIXI guide

[kiran_k8]

Avinash,

A word of caution as it is related to change in Primary keys.....

Before you move your changes to Q better take the backup of the existing entries from that table and then move your changes.

That way you will be able to compare the Old entries ( before your change moved to Q ) and the current entries (after your change moved to Q ).

If no problem with your change,then you can do the same even in P before you move your changes.

K.Kiran.

[kiran_k8]

Avinash,

Go to SE12

Give the table name and display.

Now check the following and see what info you can get,

UTILITIES>>DATABASE OBJECT>>DISPLAY

UTILITIES>>DATABASE OBJECT>>CHECK

RUNTIME OBJECT>>DISPLAY

RUNTIME OBJECT>>CHECK

RUNTIME OBJECT>>RECURSIVE CHECK

To me it seems like Table at the application level is not consistent with the table at Database level.

May be checking DB02>>Diagnostics>>Missing Tables and Indexes with the help of a Basis guy will give you an lead.

K.Kiran.

[Sandra_Rossi]

I did a test, and there was no issue turning an existing non-key field into a key field, and no issue moving an existing key field at another place in the primary key.

So, please check the SAP notes, or open a ticket to SAP support.

Or, if you want to solve immediately, create a new table from scratch, and create a program to transfer the values from the old table to the new table.

PS: of course, if you turn an existing key field into a non-key field, then you must "adapt" the table's contents using SE14, which may not be possible if there is to be duplicate entries with the new primary key.

[Sandra_Rossi]

You must have all key fields at the top of the list of fields (cut it using the button, select the row before which you want the new field, and click the paste button). Otherwise, you get the following error message, press F1 on that message to get the explanation:

Key is already defined; field ... cannot be in the key

Message no. AD434

Diagnosis

When defining table fields, you added further key fields at the end after entering a block of key fields followed by a block of non-key fields.

All the key fields of a table must be in a block at the beginning of the table.

Procedure

All key fields in a table should be entered in a single block.