Adding one column to another table with no common fields

[former_member752221]

Hello All,

I have these two tables, I_TABLE structure RSPARAMS & I_OBJECT structure VANZ. I am trying to get I_TABLE-LOW and I_OBJECT-TEXT into the same table to be able to print these two variables on the same line. However the issue I am running into is these tables have nothing in common. If there is another way to print theses variables on the same line without having them in the same table let me know. But there are multiple rows I am printing out so I need to loop through something, and if I loop through both it will create a nested loop, which I do not want.

[joltdx]

"The tables have nothing in common", you say... I assume they have something in common, or how do you know for which LOW you should print which TEXT?

Or am I totally misunderstanding? What does your data look like, and which output do you want? Can you give a minimal example?

[VXLozano]

First of all, explained like you did, this requirement has no sense at all. As Jörgen said, maybe you should provide more information about that.

But let's assume your pointy haired boss asked you to print two tables "in parallel". I'd try something like:

loop at tab1 into data(line1).
* print line1
  check sy-tabix <= lines( tab2 ).
* print tab2[ sy-tabix ]
endloop.
"Matt's refactoring begins here
if lines( tab2 ) > lines( tab1 ).
  loop at tab2 into data(line2).
*   print line2
  endloop.
endif.

Remember to loop the largest table to not lose information.

[matt]

That can be overcome by:

loop at tab1 into data(line1).
* print line1
  check sy-tabix <= lines( tab2 ).
* print tab2[ sy-tabix ]
endloop.

if lines( tab2 ) gt lines( tab1 ).
  loop at tab2 from lines( tab1 ) + 1.
* print tab2[ sy-tabix ]
endloop.

   

[VXLozano]

woooo!!
updating the answer

[matt]

tbh, I tend to use a do loop with indexed reads of the table.

None of our solutions so far work with HASHED tables. An exercise for the reader, I think.

[VXLozano]

Some day I'll check what are the benefits of non-standard tables. Call me lazy (because I am), but I declare all my internal tables as standard with empty key by default.

[matt]

Mainly speed when dealing with large tables. HASHED tables are good for buffering, and for COLLECT. SORTED tables are should be used if you ever feel tempted to use BINARY SEARCH (and don't need the table to be STANDARD for use elsewhere, e.g. with an ALV).

Btw, SORT with an empty key does nothing (assuming you've used TYPE STANDARD TABLE OF blah WITH EMPTY KEY).

Always using INSERT INTO TABLE, never APPEND, since the former works will all table types and the latter only STANDARD.

But for most purposes STANDARD is fine.

[VXLozano]

Up to now I have no problems with performance (in my developments, soon I'll have to face one that scares me because it's a spaghetti mess).
About the SORT, I never understood why people use it without a fields list. "sort by default" looks like a way to disaster. Same with ORDER BY and things like these.