Hex conversion produces different results

[matt]

I have a table with a key, and a hexvalue. The hexvalue is type data element SXIVERI_BINARY, which is RAWSTRING. In my program, I get a record, is_record, from another source. I convert this record into binary:

DATA: l_hexvalue TYPE sxiveri_binary.

me->r_conv = cl_abap_conv_out_ce=>create( encoding = 'DEFAULT' endian = space).

  if me->r_view is not bound.
    me->r_view = cl_abap_view_offlen=>create_legacy_view( is_record ).
  endif.

  me->r_conv->convert_struc( exporting data   = is_record
                                       view   = me->r_view
                             importing buffer = l_hexvalue ).

I then read a record from my Z table, with the same key. If the hexvalue in the Z table and that in l_hexvalue has changed, then I know that some field in the input record is different from that stored in the database. I then overwrite the value in the database with l_hexvalue.

The problem is this. I run the program in background - it populates my Z_table. When I run it in foreground, it tells me the calculated value is sometimes different from the value stored in the database. And it turns out, it's just ONE field that's different. An integer. In the database, I see the hexvalue 20 20 20 00 00 00 00 in l_hexvalue 20 66 6F 00 00 00 00 There are character values each so I can locate these in the hexstring quite easily. Now, the source field is type I(4). And this is being converted to 7 bytes. There are other I(4) fields in the record, these are being converted to 8 bytes.

Finally - the system the program is run on is non-unicode 7.20. The source data is unicode 7.20. When I have source data from a non-unicode I have no difficulties.

Anyone got any ideas?

matt.

[former_member194669]

No issue with the following

 The problem is this.  I run the program in background - it populates my Z_table. 
.....
.....
  When I have source data from a non-unicode I have no difficulties.

Hex value 6F is for char value = o or o

While running in the foregound are you using gui_upload ? if yes please check the documentation for import parameter CODEPAGE ( I think if your system not running on any unicode also you can use this )

a®

[former_member194669]

and also try with while converting use UTF-8 instead of default

me->r_conv = cl_abap_conv_out_ce=>create( encoding = 'UTF-8' endian = 'L' ).

instead of

me->r_conv = cl_abap_conv_out_ce=>create( encoding = 'DEFAULT' endian = space).

a®

[matt]

The data is coming via IDOC/ALE (it's BI). I've tried all combinations of encoding and endian, with different records being affected, but utlimately the same issue with the same 3 bytes!

matt

[former_member194669]

Have you checked SM59 connection setting -- specifically - MDMP&Unicode Tab ?

a®

[matt]

> Have you checked SM59 connection setting -- specifically - MDMP&Unicode Tab ?
> 
> a®s

it's good you're going through the same thought processes I did. Yes. The system we're running on is non-unicode and the connections are set correctly - on the source system also.

At little more info - the results of a few more tests. I ran the extraction to PSA only. For non-BI people this means the data is extracted from the source system and placed into a table (called the PSA). It's just an ordinary table.

I then ran the the transfer rules ("the program"), in simulation mode, so that I can debug it. I check the value of the hex conversion - specifically the three offending bytes. I then restarted RSA1 transaction, and did it again. The bytes were different.

So - the data is coming from exactly the same source, within the sytem. And I get different results each time I run it. ( Actually, it's in a cycle. The integer field has value 0. When I look at the text of the hex, it goes between IS0, AV0 and lan, the next four bytes are always x00. ).

I think, therefore, this is a bug in the conversion, and I've enough info to send it to SAP. Unfortunately, the system I'm running this on isn't available today, so I'll have to wait until tomorrow. In the meantime, if anyone has some more thoughts, they'll be gratefully received!

cheers

matt

[matt]

SAP got back to me, and the answer is - it's to do with alignment.

If you have a structure like this:

DATA: BEGIN OF s_mystruc,
                 f1 TYPE c LENGTH 1,
                 f2 TYPE int4,
         END OF s_mystruc

it is stored as xx yy yy yy zz zz zz zz, where xx is the hex for f1, and zz is the hex for f2. The yy are alignment hex values, because int4 MUST be at an address divisible by four. ( In this case, xx is at position 0 ).

The yy values are just whatever happens to be at the memory location. They're not set to x00 before the conversion. I have found a workaround though, which gets rid of the need for the convertors for my applications.

FIELD-SYMBOLS: <l_hexvalue> TYPE x.

ASSIGN is_record TO <l_hexvalue> CASTING.

When I use this, the alignment hex values are always x00, and my program works.

matt