topic Re: move-corresponding in Application Development and Automation Discussions

move-corresponding

Former Member — Mon, 06 Aug 2007 09:51:56 GMT

Hi,

Is this line a cause to performance issue?

MOVE-CORRESPONDING t_bt_pos_match TO t_db_match_send.

The tables used here are having 10 fields each.

Shall I enter values in each field individually or its ok to use this statement ?

Thanks,

Binay.

Re: move-corresponding

gopi_narendra — Mon, 06 Aug 2007 09:54:11 GMT

It causes a performance issue.

Its better to move each field individually instead of using move-corresponding.

Regards

Gopi

Re: move-corresponding

Former Member — Mon, 06 Aug 2007 10:17:09 GMT

its depends on data how much ur passing one table to another.

If internal table contains lacs of data better u need to use move with each field.

Re: move-corresponding

Former Member — Mon, 06 Aug 2007 10:38:59 GMT

the move-corresponding does not come for free, but I don't think that it causes a performance problem.

Be aware that if the structures change, then the move-corresponding will still work.

Generally it is of course recommended to use identical structures, if possible.

Siegfried

Re: move-corresponding

Former Member — Mon, 06 Aug 2007 10:44:54 GMT

MOVE-CORRESPONDING Should not cause performance issues. It will work in mojority of cases. If your development guidelines does not restrict the usage, it will be good to use it.

Regards,

Vishal

Re: move-corresponding

Former Member — Mon, 06 Aug 2007 11:02:54 GMT

for completeness,

move-corresponding should not be used with selects to buffered tables. The runtime on the table buffer is much faster, such that you will notice the time for the move-corresponding, in relation to the buffer access.

There it makes sense to do direct moves of the few wanted fields.

In relation to database select the move-corresponding should not play a role.

Siegfried

Re: move-corresponding

seshatalpasai_madala — Mon, 06 Aug 2007 11:10:22 GMT

Hi,

If both the tables have same fields, With respect to their type and length then you can just use = or MOVE.

MOVE-CORRESPONDING should be used only when you want to move the data based on field names.

The performance of MOVE Is better than MOVE-CORRESPONDING since here you dont compare the field names but just do a byte/char sequence copy.

Regards,

Sesh

Re: move-corresponding

Former Member — Tue, 07 Aug 2007 07:56:25 GMT

Hi,

Don’t use Move-corresponding statements normally because it affects the performance, so it is better to avoid this statement whenever possible.

Anyway you have only 10 fields so that you can use the 'move' statement for each field instead of Move-corresponding statement.

Regards,

Vijay

Re: move-corresponding

KjetilKilhavn — Tue, 07 Aug 2007 08:00:13 GMT

> Be aware that if the structures change, then the

> move-corresponding will still work.

> Generally it is of course recommended to use

> identical structures, if possible.

MOVE-CORRESPONDING is a beautiful statement. Very nice if you want to join information from various structures into one. However, it does have one disadvantage - which is also its strength mentioned by Siegfried.

If you change an include that is used in both structures, everything works without any needs for updating the code. However, if you remove a field from an include, or a list of selected fields, you don't get any warnings that you were actually using this field for something.

I would say the advantages outweigh the disadvantage, but I have kicked myself a couple of times after finally finding out why my code didn't work as I expected.