Professional Documents
Culture Documents
Unicode Conversion Preparation PDF
Unicode Conversion Preparation PDF
1
Conversion Preparation
2
Upgrade Path to the Unicode ( R/3
Enterprise)
3
Concept Contd:
4
Why MDMP/Ambiguous Conversion is
complex?
5
Content of the Unicode system is as shown below in
comparison to the above diagram:
6
Concept: Conversion Preparation
7
SPUMG : Conversion Preparation
8
SPUMG Contd.
9
SPUMG: Language Lists
10
SPUMG Settings: Maintain the SPUMG settings and
then initialize the worklist for the Consistency checks
11
Consistency Checks:
•Classifies tables into tables with/without language
filed information ( Table category 1 and 2 ).
•Checks table consistency ( existence, access)
•Writes control information to SPUMG control tables
( Table category, Language Field)
12
Tables without Language Information: This scan adds
words to the system Vocabulary and all the all the
tables without language ( Table category 2 )
information are scanned.
13
Tables with Ambiguous Language Information: All the
tables with language information ( Table Category 1 )
are scanned. Words with an ambiguous language are
added to the System Vocabulary.
Only active if ambiguous language list has been
maintained.
14
System Vocabulary
15
Tables with Language Information: All tables with the
language information are scanned ( Table category 1 ).
This scan assign the language to the words in the
System Vocabulary based on the values of the other
tables in the database.
Only problem could be Vocabulary Collisions.
16
Reprocess: This scan simulates the R3load behavior. It
checks if the code page information in the System
Vocabulary is sufficient for the conversion. If not, this
scan creates a repair Log for the table. ( Row identifier
+ Language assignment )
17
Reprocess Repair Log : It contains table name, key
values, reason why no code page could be assigned.
Users can assign a language to each entry here. This
information is used in the Unicode system to repair
wrongly converted data.
INDX-type Tables: Special Treatment
18
Structure of the INDX-type tables as shown in the
below diagram:
19
INDX-type table repair/analysis : These two scans treat
the binary part of INDX-type tables:
1. All INDX-type tables without language information
are scanned and all the text hidden in the INDX-cluster
part is analyzed. Words are added to the system
Vocabulary.
2. System Vocabulary is used for assigning correct
code pages before the database export.
20
Final steps in the non-Unicode systems
21
Database Export, Conversion and
Import
The system setup tool SAPinst is used for the entire system
copy – internally SAPinst uses the program R3load.R3load
performs the database export with the conversion to Unicode
using the control table and System Vocabulary, writes an
R3load Repair log in case the code information is not
available, and performs the database import. As a system
copy to Unicode, database conversion and system shutdown /
Unicode system start will be completely automated.
22
R3load – Export :
SAPinst uses a program R3load as a Frontend tool for
the database export.
Logs are written to the SAPinst Directory
Export files are written to the Export Directory
R3load – Import :
SAPinst uses a program R3load as a Frontend tool for
the database import.
Non-UC DB can be deleted ( not recommended) or UC
DB can be installed on the new / different server.
Import method is same as new installation.
23
R3load – Export
24
R3load -- Import
25
Unicode System: Initial Steps
1. Update the kernal and other executables
2. Start the Server.
3. Logon to the Unicode System and run SICK.
See the diagram below for the overview:
26
SUMG: On the UC System
27
SUMG: After the database import there might be some
data in the Unicode system which need to be
“repaired”. In this case the data can be converted
again, using the correct language information (code
page).
SUMG has several repair methods:
1. Repair Jobs, using the R3load Repair Log and the
language information of the SPUMG reprocess Log.
2. Repair Hints.
3. Manual Repair.
28