topic Re: TABLE TRANSPORT PROBLEM in Application Development and Automation Discussions

TABLE TRANSPORT PROBLEM

Former Member — Tue, 13 Jul 2010 00:56:20 GMT

i am in a real fix, i want to know the proper way of transpoprting table entries from dev server to q/a, prod

i came across 2 ways

first way

se11 => ztable.

menu => transport entries

assign it to a req no.

check in se09 /10

release.

(i am giving the link)

Link:[http://sample-code-abap.blogspot.com/2008/06/transporting-table-entry.html]

second way

table: ztable.

go to se10 =. display => workbench request.

dbl clk the req number.

now in change mode in 'objects' tab => object name = ztable. clk on 'functions' key.

a new screen appears => dbl clk on the first empty line.

provide the table entries to be transported.

select the radiobutton 'entire table / table contents as per req / table contents by current key '.

save.

**----

which of the above is correct and wats the diff ? pls suggest. which one shud i follow?

Re: TABLE TRANSPORT PROBLEM

RichHeilman — Tue, 13 Jul 2010 02:06:35 GMT

Both ways produce the same results, but it is easier to do it the first way. You can simply select the records, and choose from the menu, and the entries will be added to the request.

Regards,

Rich Heilman

Re: TABLE TRANSPORT PROBLEM

romanweise — Wed, 14 Jul 2010 18:07:18 GMT

Hi,

both procedures have the same result but unfortunately both have the same restrictions and lead to the same errors.

Tables which need transportation should always be defined and maintained in a way that the transport integration is ensured. This includes the correct table type (e.g. C table for customizing), maintenance only via maintenance view (generated or own defined) and transport integration activated (TCode SCC4). This is the only way the consistency between the systems is ensured. If you only put the table entries into a transport from time to time you only send the current table lines but deletion of lines won't be transported so you will end with more / outdated lines in qa and prod system. So if your z table contains customizing information you should define it as table type C, generate a maintenance view and maintain it e.g. via T-Code SM30. So every time someone changes the entries a transport request pops up automatically.

While this all does not seem to difficult to handle for small developments, propper transport integration and table definition is important if you head into greater projects perhaps with delivery to multiple customers. In such scenarios it is very important for the software logistic guys that the developers keep the basic rules for table definition as no S type table w/ client field, never put an integer type field into table key, never put asterisks in customizing transport (except langu field), never use the wrong transport type by manually adding table entries in workbench transports which belong in customizing ones and so on. It's really no fun if one year of development w/ some thousand man days of work can't be delivered because one of 2k tables was not defined properly.

Kind regards

Roman