Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SUMG Free Repairs (MDMP System)

Former Member
0 Kudos

Dear community,

I've converted a non-Unicode 4.6C MDMP system to ERP 6.0 Unicode with the UC&CU guide. After the conversion, I discovered that in SUMG (after loading the R3load logs) a huge list of tables are in category "free repair" with this text:

The whole table was converted using the default code page.Please check the data.

When logging on with a latin2 codepage, I get wrong characters (those of latin1 which was defined as fallback option in SPUM4). Do you have any idea why all these tables are converted using the default codepage? We maintened the vocabulary and executed some hints in 4.6C, everything was prepared correctly...

Regards,

Pascal

1 ACCEPTED SOLUTION

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Pascal,

first of all you need to check why the tables where converted using the default code page.

Please have a direct look into the r3load xml files.

One reason could be that the tables where not included in the export control table UMGCCTL.

Then the problem typically needs to be analyzed in the source system (Non-Unicode). Unfortunately in many cases it is

not possible to find the problem in the Unicode system.

Best regards,

Nils Buerckel

SAP AG

10 REPLIES 10

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Pascal,

first of all you need to check why the tables where converted using the default code page.

Please have a direct look into the r3load xml files.

One reason could be that the tables where not included in the export control table UMGCCTL.

Then the problem typically needs to be analyzed in the source system (Non-Unicode). Unfortunately in many cases it is

not possible to find the problem in the Unicode system.

Best regards,

Nils Buerckel

SAP AG

0 Kudos

Hi Nils,

thanks for your helpful answer. I checked the xml files, I found a lot of entries like this:

- <PROBLEM_TABLE>

<NAME>/BEV3/CHKASTATUS</NAME>

<BEGINTYPE>B</BEGINTYPE>

<CAT>1</CAT>

- <!-- 1==normal table -->

<TAB_USED_CP>1100</TAB_USED_CP>

***- <!-- Cannot read UMGCCTL. -->***

<ENDTYPE>F</ENDTYPE>

</PROBLEM_TABLE>

Is this the problem? Seems like UMGCCTL cannnot be read, how can this happen? At the begginning of the xml the table can be read:

<!-- matches : 6

-->

- <!-- language re-mapped: 4

-->

- <!-- languages added : 27

-->

- <!-- code pages added : 10

-->

- <!-- language ambiguous: 7

-->

- <!-- languages removed : 0

-->

- <!-- GetDBMigrateCodePagesLangs: reading UMGCCTL:

-->

- <!-- code pages added : 0

-->

- <!-- UMGSETTING-GLOBALFBCP : 1160.

-->

- <!-- MINWORDLN : 1.

-->

- <!-- UMGCCTL talks about 28348 tables.

-->

0 Kudos

HI again,

after somre more investigation I found out that the export control table of the non-Unicode system seems corrupt after the upgrade. The UM4CCTL table was correctly filled with the table names, but then after the upgrade, the corresponding UMGCCTL table has garbage texts in the table name field like these ones:

/"$,/#?=>

/"$,/#}.>!"

/"$,/$%=>

/"$,/&?:$!>

/"$,/&?:>^:

/"$,/(%!$

/"$,/)"?=

/"$,/)&#(!

/"$,/)&$%&

/"$,/)&%]#

/"$,/)&%]:

/"$,/)&&)%,$

/"$,/<&#$%=>

What could be the reason? It makes sense, that R3load sees 28000 entries in this table, but does not know what to do with them because it can't find the table...

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Pascal,

did you execute the report um4_finish_preparation in the non-unicode system after the upgrade and before the export as outlined in the cu&uc guide (4.1 --> point 6) ?

Best regards,

Nils Buerckel

SAP AG

0 Kudos

Hello,

I'm doing upgrade from 4.6C to ECC 6.0 EHP4 SR1. (NOT MDMP)

I've got same issue.

Could you share the solution for that?

Symptom)

During upgrade, I've finished the preparation for unicode conversion in SPUM4.

At that time, UMGCCTL is fine. (The number of UMGCCTL is around 25,000)

After upgrade, before executing UM4_FINISH_PREPARATION,

The number of UMGCCTL is same as before, but table name is filled out with special characters.

After executing UM4_FINISH_PREPARATION,

the number of UMGCCTL is around 120,000, and the number of garbage data is almost same.

How could you fix it? What's the root cause?

And can I ignore it and proceed it?

Thanks.

Edited by: Sunghoon Wui on Jul 2, 2011 7:34 AM

Edited by: Sunghoon Wui on Jul 2, 2011 7:53 AM

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

this is the normal behaviour.

During the upgrade, the table entries are converted to some unreadable code (examples listed above).

Then UM4_FINISH_PREPARATION reconverts these entries to readable words.

However it does not delete the old entries ( there is no need for it and it makes error analysis easier to keep the entries).

In addition, the new tables from ERP are added to UMGCCTL (that is why the number of entries are higher compared to 4.6C).

Best regards,

Nils Buerckel

0 Kudos

Dear Nils,

Thank you for your kind explanation.

#####################################################################################################

Hi,

this is the normal behaviour.

During the upgrade, the table entries are converted to some unreadable code (examples listed above).

Then UM4_FINISH_PREPARATION reconverts these entries to readable words.

=> After execution UM4_FINISH_PREPARATION, huge unreadable codes still exist.

However it does not delete the old entries ( there is no need for it and it makes error analysis easier to keep the entries).

In addition, the new tables from ERP are added to UMGCCTL (that is why the number of entries are higher compared to 4.6C).

####################################################################################################

My concern is the loss of data "Export control tables" (which are created by SPUM4 before downtime phase).

And is there any problem during export / import / completion of unicode conversion from unreadable entries?

Thanks again.

Best Regards,

Sunghoon Wui

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi Sunghoon,

as I tried to describe above: this is not data loss, but rather conversion and reconversion.

If you want, you can spot check single entries in the table in 4.6C and in ERP 6.0 after executing UM4_FINISH_PREPARATION.

But anyhow I would recommend to test this on a Sandbox system.

Best regards,

Nils

0 Kudos

Dear Nils,

Thank you!!

nils_buerckel
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi all,

now this issue is described in SAP note 1607053.

Best regards,

Nils Buerckel