ECC 5.0 Unicode error

Question

Hi,
During the upgrade from 4.6B to ECC 5.0, we are facing the following problem:
In 4.6B, when we move the contents of one internal table to another ( itabA[] = itabB[] ), its happening properly, even though the structure of both the internal tables are not the same i:e itabB has more fields than itabA.
But, this doesn't happen in the case of ECC 5.0. Its throwing some UNICODE error, saying that the structure isn't the same.
If anyone has come across this problem, please revert with the solution.
Thanks,
Raj.

Answer 1

hi,
We are getting error because of unicode issues. We get this problem bcos of Alignment gaps.
Hope the below explanation helps you..
To check whether two structures can be converted at all, the Unicode fragment view of the structures is set up initially by combining character type groups, byte type groups, alignment gaps, and other components. If the type and length of the fragments of the source structure are identical in the length of the shorter structure, the structures can be converted. Assignment is allowed under the following conditions:
The fragments of both structures up to the second-last fragment of the shorter structure are identical
The last fragment of the shorter structure is a character or byte type group
The corresponding fragment of the longer structure is a character or byte type group with a greater length
If the target structure is longer than the source structure, the character type components of the remaining length are filled with blank characters. All other components of the remaining length are filled with the type-adequate initial value, and alignment gaps are filled with zero bytes. Since longer structures were previously filled with blanks by default, using initial values for non-character type component types is incompatible. This incompatible change is, however, rather an error correction. Character-type components are not filled with initial values, for the sake of compatibility.
Example
BEGIN OF struc1,                     BEGIN OF struc2,
  a(1) TYPE C,                         a(1) TYPE C,
  x(1) TYPE X,                         b(1) TYPE C,
END OF struc1.                       END OF struc2.
You cannot use the struc1 = struc2 assignment in Unicode, because struc1-x only occupies one byte, in contrast to struc2-b.
BEGIN OF struc3,                     BEGIN OF struc4,
  a(2) TYPE C,                         a(8) TYPE C,
  n(6) TYPE N,                         i    TYPE I,
  i    TYPE I,                          f   TYPE F,
END OF struc3.                       END OF struc4.
The struc3 = struc4 assignment is valie because the fragment views of the character-type fields and the integer numbers match.
BEGIN OF struc5,                     BEGIN OF struc6,
  a(1)  TYPE X,                        a(1) TYPE X,
  b(1)  TYPE X,                        BEGIN OF STRUC3,
  c(1)  TYPE C,                          b(1) TYPE X,
END OF struc5.                           c(1) TYPE C,
                                       END OF struc3
                                     END OF struc6.
However, struc5 = struc6 is not permitted - the fragment views of the two structure are different, because of the alignment gaps before struc3 and struc3-c.
BEGIN OF struc7,                     BEGIN OF struc8,
  p(8)  TYPE P,                        p(8) TYPE P,
  c(1)  TYPE C,                        c(5) TYPE C,
END OF struc7.                         o(8) TYPE P,
                                     END OF struc8.
The struc7 = struc8 works because the fragment views in the length of the structure struc1 match.
For deep structures, the operand types must be compatible as usual. We enhanced the concept by generalizing to some extent the convertibility of object references and table components.
Regards,
Sailaja.