Transporting Table entries

[Murali_Shanmu]

Hi,

I have a table which has three key fields of which one of the key field is a GUID field of data type CHAR 255.I have 500 records in this table. I need to transport the table contents to the next system (TST)

As per the below documentation, its not possible to transport the table contents as the length of the key fields is very large. I do not want to try transporting the contents generically as stated in the below document since one of the key field is a GUID.

Creating Tables -  ABAP Dictionary - SAP Library

Does anyone have an idea as to how I could keep the contents of this table same in both DEV and TST.

Thanks,

Murali

[matt]

Write a program that downloads the data and another one which uploads it. Download in dev. Upload in test.

[Murali_Shanmu]

Thanks Matthew. I am aware of this option, but the only challenge I have with this customer is that they do not allow handling of files in PRD due to security reasons.

[Jelena_Perfiljeva]

Murali Shanmugham wrote:

Thanks Matthew. I am aware of this option, but the only challenge I have with this customer is that they do not allow handling of files in PRD due to security reasons.

No files at all in PRD? How do they get anything done? And what exactly is "security reason"?

Do they allow RFC, web services, remote database connection then?

[Murali_Shanmu]

Hi,

This customer always use transports as the only mechanism to push contents into PRD. I think it is the fear of the data being manipualted if it is stored in a file and used for upload in all the environments (however, this table doesnt have anything significantly important )

[matt]

I think you'll find that "business requirement" beats "security reasons" every time. Especially when those security reasons are a bit... dare I say, silly? I'm amazed they let people type things into transactions. What if they manipulate that data?

[Murali_Shanmu]

Agree

[Former Member]

If you want to move all the data in the table the generic transport should be just fine.

You might want to revisit the design decision to make the key that large though.

[Murali_Shanmu]

Thanks Gerrit. I dont think I can transport the table generically as one of the key fields is a GUID. Hence, I cannot use * as a character at the end.

I am dealing with a unique requirement where the Standard table has a large key length and I am trying to transport the table contents to avoid manually keying in the same contents in all the systems in the landscape.

Below is the standard table

and the contents as shown below

Thanks,

Murali.

[Jelena_Perfiljeva]

Murali Shanmugham wrote:

I am trying to transport the table contents to avoid manually keying in the same contents in all the systems in the landscape.

Wait, what? You can just use SM30? You said the table had 500 entries. With a good size monitor you can copy-paste 20 entries at a time in SM30. Even if each screen takes you the whole minute you'd be done in 25 min.

[Former Member]

Jelena,

One of the key fields was 255 characters.  ALV has a field limit of 128. So if he used SM30 to copy from one system to another, he would lose any of the characters in position 129-255 when he copied and pasted the rows.

[Former Member]

If you need to move all the entries from Dev to other systems there is no need for a partial key in the transport. We have a table with the same problem and just move it with a transport, the only problem now is that we always have to move the complete table every time but it does work.

[Murali_Shanmu]

Thanks for all your response.I think the only way I could proceed is to transport the complete table as a whole from DEV to TST always.