ABAP structure mismatch issues

[Former Member]

Greetings everyone.

We have got an ABAP issue in our developement system.

There is a work area W1, with structure, 'A', with fields 'F1', F2' & 'F3'.

There is an internal table T1, with structure 'B', with fields 'F1', 'F2', 'F3' & 'F4' . [fields from structure A + field 'F4']

When the program loops at the internal table and tries filling into work area, we are getting a runtime error.

      "Conversion of type "v" to type "***" not supported. "

But the same program works just fine in our production system. And i have checked, there is no version mismatch between the systems.

My assumption is maybe unicode check is active in Development system. But is there any way to verify this? Is there any place where some setting is maintained forcing an unicode check.[when i check the attribute screen for the include and main program, i could not find the 'unicode checks required' check box]

Or is there any other reason we could be getting this error.

Please let me know your answers.

Regards,

Joshua.

[Former Member]

Hi,

   I have few questions for you...

  Are you getting this conversion problem with fourth field.

  One more question if it has an issue in development system.how it is moved to production?

[Former Member]

Thanks Querty for your reply.

The runtime error lists the whole structure, it says "Conversion of type "v" to type <the structure used in the worka area> not supported". It does not specify a single field. The only difference i find here is the structure mismatch between the internal table and work area.

Regarding your second question, i am not sure. It was probably working fine in developement when they tested. [just like it is working well in production now]. Or may be they did not test the scenario where this code gets called and moved it to production. Either way, the user is not getting this error when the program is executed in production. So, i thought it may be related to unicode checks.

Regards,

Joshua,

[Former Member]

Hi,

Have you checked the data types of structure A and B are matching?

Thanks

Venkat

[Former Member]

You can check if your program is Unicode compliant by using transaction uccheck.

However, I would try to make the structure of the work area and the internal table the same, or use a construction with 'into corresponding fields of' .

good luck

[Former Member]

Hello Namitha and Spronk, thanks for your advice on using move-corresponding.

But what i need to know here is, why is it working in development and not in production. My guess was in development unicode check is active and in production it is not. Because i have heard somewhere that unicode compatible programs will require the structures to match and plain old assignment of one work area to another will not work. If that is the case, where is the configuration maintained, because i could not see anything in the attribute screen.

We have tried the UCCHECK, it is not listing any program from the concerned package.

Regards,

Joshua.

[Former Member]

Hello,

check the datatypes are same for the fields in the work area and internal table.

while moving or selecting fields,use move corresponding fields.....

or select f1,f2 into corrresponding fields.....

Regards,

[Former Member]

Hi,

You can use INTO CORRESPONDING FIELDS in select query, but again it will affect performance of the program. so its better you can add that extra field into structure of your work area.

[nils_buerckel]

Hi Joshua,

I think someone has ticked the Unicode flag of that particular object.

In SE38, you can have a look at the attributes and then check the

"Unicode checks active" flag.

If this is ticked, the Unicode syntax check is active and gives you messages like the one you mentioned.

In PRD I assume this flag is not checked.

Best regards,

Nils Buerckel