UNICODE conversion of Siebel Database- Impact on interface

Hi All,
This is regarding the impacts on Interfaces after Siebel database UNICODE conversion.
We are planning to do a UNICODE conversion of the Siebel database.In the current landscape we have Siebel interacting with multiple application which are non UNICODE.
Majority of the interfaces(outbound/inbound) are batch interfaces which either use file or PL/SQL + EIM for the data transfer.
We have the following queries about the impact on the Interfaces post conversion
1) the Interfaces which are outbound from siebel to non -unicode database what will be impact on these interface.
2) For the above mentioned interfaces do we need to do some conversion of data before it gets loaded to non unicode database.
3) for the inbound interfaces will the siebel unicode data base will allow the data which is flowing from non unicode database.
Could you please guide me with your experiences which will help us in planning this conversion.
Do let us know if there must to consider points for Siebel database unicode conversions
Thanks,
Ashutosh

Ashutosh,
Did you already start on the Unicode conversion?
We contacted Oracle, but so far they only said we need to go through a workshop where we can estimate the impact on the interfaces.
Since we need to do a cost/benefit analyses before we decide to do this, it's hard to do so when you don't know the impact on the interfaces.
In our case we use EIM, Web Services, MSMQ (XML) and flat files.
Anyone with experience with a conversion to Unicode and impact on interfaces?
Ji Yong

Similar Messages

SCM Unicode Conversion - Initialize LC or not??

We have recently upgraded our non unicode SCM 5.0 systems to SCM7 EhP3 and we now want to convert these systems to Unicode.
We will be running most of the unicode conversions in situ, ie run all the unicode conversion steps and /SAPAPO/OM_LC_DOWNLOAD_UPLOAD (A&B) , export the database, drop the original non unicode system, reinstall a unicode SCM system and then import the database, followed by /SAPAPO/OM_LC_DOWNLOAD_UPLOAD (C) etc..
On one of the servers however we have 2 SCM systems installed and will use the unicode conversion to move one of the SCM systems to a new server during the database export/import phase, so finally down to my questions!
1) For the in situ Unicode conversions, I take it that we DO NOT have to initialize LC when reinstalling the Unicode SCM system and that we can use param_put DEFAULT_CODE Unicode and alter user SAP<SID> DEFAULTCODE UNICODE before running Step C of /SAPAPO/OM_LC_DOWNLOAD_UPLOAD?
2) For the Unicode conversion including the database export/import (homogenous system copy) to the new server, do we have to initalize livecache as part of the SCM install?
Regards,
Mark

Hi Mark,
Please cehck below thread,
Restore backup of a Non Unicode to a Unicode Live Cache
1319517 - Unicode Collection Note
BR
AKJ

Error while database export in package SAPDODS_33 (Unicode conversion)

Hello,
I am performing Unicode conversion on an upgraded BI 7.0 system. This is running on AIX/DB2.
When I take database export for conversion, one package fails (SAPDODS_33) with error "The file system is full". In fact, df -k doesn't show that any file system is full.
I am taking the export to the following location: /db2/BWS/sapdata/EXPORT_DIR
There are 3 system-managed temporary tablespaces: PSAPTEMP, PSATEMP16 & SYSTOOLSTMPSPACE which were residing in /db2/BWS/saptemp1/NODE0000. This was getting full during the export. Now these temp.tablespaces have been relocated to a new file system of size 15GB.
But still the package SAPDODS_33 doesn't get exported. Could you please let me know how to solve this issue?
Thanks a lot!
Sundar.
=====================================================================================
SAPDODS_33.log
(DB) INFO: connected to DB
(rscpsumg) Please look also into "SAPDODS_33012.xml".
(rscpMC) Warn: env I18N_NAMETAB_TIMESTAMPS = IGNORE
(rscpMC) Warn: UMGCONTAINER has 1 problems.
(rscpMC) Warn: Global fallback code page = 1160
(rscpMC) Warn: Common character set is not 7-bit-ASCII
(rscpMC) Warn: Collision resolution method is 'fine'
(rscpMC) Warn: R3trans code pages = Normal
(rscpMC) Warn: EXPORT TO ... code pages = Normal
(rscpMC) Warn: Source is 'MDMP'
(rscpMC) Warn: I18N_NAMETAB_NORM_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_NORM_LOG   = 0
(rscpMC) Warn: I18N_NAMETAB_ALT_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_ALT_LOG    = 0
(rscpMC) Warn: I18N_NAMETAB_OLD_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_OLD_LOG    = 0
(GSI) INFO: dbname   = "BWS
(GSI) INFO: vname    = "DB6                             "
(GSI) INFO: hostname = "UNKNOWN
(GSI) INFO: sysname = "AIX"
(GSI) INFO: nodename = "itmlartdev01x"
(GSI) INFO: release = "3"
(GSI) INFO: version = "5"
(GSI) INFO: machine = "002417CA4C00"
(GSI) INFO: instno   = "0020169337"
(EXP) ERROR: DbSlExeRead failed
rc = 99, table "/BIC/B0000786000"
(SQL error -968)
error message returned by DbSl:
SQL0968C The file system is full. SQLSTATE=57011
(DB) INFO: disconnected from DB
/usr/sap/BWS/SYS/exe/run/R3load: job finished with 1 error(s)
/usr/sap/BWS/SYS/exe/run/R3load: END OF LOG: 20071211053119
p/sapinst/sapinst_instdir/NW04S/LM/COPY/DB6/EXP/CENTRAL/AS-ABAP/EXP #

Hi Sundar,
if the problem is due to a high temp space usage. The root cause is typically the
sort during export. If the table is large, the sort spills to temp.
You can avoid the sort by doing an unsorted export or tweak the DB2 optimizer to use the primary key to do the sort.
Before DB2 9, you can reduce the OVERHEAD tablespace parameter to zero. Return this value to its previous value after the successful export. This is a indirect hint to the optimizer that random IOs are cheap. This might not help.
With DB2 9, this should not happen, because the DB2_OPT_MAX_TEMP_SIZE=10240 registry variable is set under DB2_WORKLOAD=SAP which limits the temp space usage to 10GB if possible. You can reduce this parameter further if necessary. Another problem could be that the optimizer has chosen the wrong temp space. The optimizer choses the temp space with the largest amount of pages (not size).
Regards, Jens

BI Unicode Conversion impact on Microsft office tools

Hello Friends,
The BI version is BI 7.0, but we are using both Bex 3.x and Bex 7.0.BI 7.0 is being Unicode converted.
Questions
Does Unicode conversion have any impact on running the new/existing reports in 3.x and 7.x
Does Unicode conversion have any impact on running the new/existing WAD reports.
Does Unicode conversion have any impact on any of the Microsoft office products used by BI.
Thanks!

Since Excel is the starting point for BEx Analyzer, Excel 2007 would need to be tested. In BEx Web, if you have Excel as a save as option for queries, you will need to test that too. It also requires that the .NET Framework 3.0 be on the end user machine.
See [OSS Note 1013201|https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1013201]

Uninstall Database manually for Unicode Conversion

Hi Guys,
While performing a Unicode Conversion, during Export, Unistall and Import of Database, I would like to improve times for Database Creation since its 5TB
My goal is to delete SAP/DB Instance Non-Unicode but keeping Tablespaces and Datafiles Layout, in order to not recreate them when re-installing SAP/DB Instance Unicode
According to SAP Note 1260050 - UNIX:Deleting Oracle DB Instance Based on NW7.1 and Higher, the steps are the following.
drop user SAP<SCHEMA_ID> cascade;
drop tablespace <TABLESPACE_NAME> including contents;
Are this steps valid to delete a ABAP Database, and keeping Datafiles structures for when Installing Unicode SAP Instance?
Thanks!

The drop command "including contents" will delete the datafiles... thus SAPinst will have to create them again... and it can take while for a 5 Tb DB.
SAPinst is supposed to recreate the whole DB thus you should entirely delete it
startup mount exclusive restrict
drop database;
One solution would be to keep the datafiles
=> just run the first SQL command : drop user SAP<SCHEMA_ID> cascade;
and play with sapinst option SAPINST_SET_STEPSTATE to skip the DB creation step

Print Servers Impact after unicode conversion

Hi
We are performing an CUUC from 4.6C to ECC 6.0
Our customer has around 4-5 windows special print servers which are used for chinese, japanese, korean printing..etc.
After the upgrade & unicode conversion
- Do we still need to use all these 4-5 special print servers for each languages seperatly? or
- We shall consolidate all these print servers into one print server? Or
- We don't need to have any print servers, all the print queues can be pointed to unix print queues and then to the printers directly.
Kindly advise
Thanks & Regards
Senthil

I would think you could consolidate the print servers, but you still need the separate printers/device types in SAP. We use a single print server for EN/DE/ZH but have different SAP printers (usinging different device types) for EN/DE & ZH printers.

Unicode Conversion

Hi ,
       We are into the initial phase of upgradation from 4.6 to ECC6 .
ineed some of the questions below ...
1.    what is mean by unicode conversion ?
2.    in an object example reoprt or script or bdc or module pool objects what are      need to be done to convert it as ab unicode object ?
3.    next is after working on the unicode object we need to work on the spoue objects .what is mean by that ?
could you guys can clear my dought for the above mentioned question ?
thanks,
vinay

plz go through the following links.....
http://help.sap.com/saphelp_nw04/helpdata/en/79/c5546db3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c55470b3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c55473b3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c55476b3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c5547cb3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c5547fb3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c55482b3dc11d5993800508b6b8b11/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/79/c55485b3dc11d5993800508b6b8b11/content.htm
The Link will be helpful to you.
Re: Upgrade 4.6 to ECC - What are the responsibilites
regarding Unicode influence in Standard programs
Very good document:
http://www.doag.org/pub/docs/sig/sap/2004-03/Buhlinger_Maxi_Version.pdf
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d37d1ad9-0b01-0010-ed9f-bc3222312dd8
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/589d18d9-0b01-0010-ac8a-8a22852061a2
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f8e316d9-0b01-0010-8e95-829a58c1511a
You need to use the transaction UCCHECK.
The report documentation is here
ABAP Unicode Scan Tool UCCHECK
You can use transaction UCCHECK to examine a Unicode program set for syntax errors without having to set the program attribute "Unicode checks active" for every individual program. From the list of Unicode syntax errors, you can go directly to the affected programs and remove the errors. It is also possible to automatically create transport requests and set the Unicode program attribute for a program set.
Some application-specific checks, which draw your attention to program points that are not Unicode-compatible, are also integrated.
Selection of Objects:
The program objects can be selected according to object name, object type, author (TADIR), package, and original system. For the Unicode syntax check, only object types for which an independent syntax check can be carried out are appropriate. The following object types are possibilities:
PROG Report
CLAS Class
FUGR Function groups
FUGX Function group (with customer include, customer area)
FUGS Function group (with customer include, SAP area)
LDBA Logical Database
CNTX Context
TYPE Type pool
INTF Interface
Only Examine Programs with Non-Activated Unicode Flag
By default, the system only displays program objects that have not yet set the Unicode attribute. If you want to use UCCHECK to process program objects that have already set the attribute, you can deactivate this option.
Only Objects with TADIR Entry
By default, the system only displays program objects with a TADIR entry. If you want to examine programs that don't have a TADIR entry, for example locally generated programs without a package, you can deactivate this option.
Exclude Packages $*
By default, the system does not display program objects that are in a local, non-transportable package. If you want to examine programs that are in such a package, you can deactivate this option.
Display Modified SAP Programs Also
By default, SAP programs are not checked in customer systems. If you also want to check SAP programs that were modified in a customer system (see transaction SE95), you can activate this option.
Maximum Number of Programs:
To avoid timeouts or unexpectedly long waiting times, the maximum number of program objects is preset to 50. If you want to examine more objects, you must increase the maximum number or run a SAMT scan (general program set processing). The latter also has the advantage that the data is stored persistently. Proceed as follows:
Call transaction SAMT
Create task with program RSUNISCAN_FINAL, subroutine SAMT_SEARCH
For further information refer to documentation for transaction SAMT.
Displaying Points that Cannot Be Analyzed Statically
If you choose this option, you get an overview of the program points, where a static check for Unicode syntax errors is not possible. This can be the case if, for example, parameters or field symbols are not typed or you are accessing a field or structure with variable length/offset. At these points the system only tests at runtime whether the code is sufficient for the stricter Unicode tests. If possible, you should assign types to the variables used, otherwise you must check runtime behavior after the Unicode attribute has been set.
To be able to differentiate between your own and foreign code (for example when using standard includes or generated includes), there is a selection option for the includes to be displayed. By default, the system excludes the standard includes of the view maintenance LSVIM* from the display, because they cause a large number of messages that are not relevant for the Unicode conversion. It is recommended that you also exclude the generated function group-specific includes of the view maintenance (usually L<function group name>F00 and L<function group name>I00) from the display.
Similarly to the process in the extended syntax check, you can hide the warning using the pseudo comment ("#EC *).
Applikation-Specific Checks
These checks indicate program points that represent a public interface but are not Unicode-compatible. Under Unicode, the corresponding interfaces change according to the referenced documentation and must be adapted appropriately.
View Maintenance
Parts of the view maintenance generated in older releases are not Unicode-compatible. The relevant parts can be regenerated with a service report.
UPLOAD/DOWNLOAD
The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.
Plzz Reward if it is useful

R/3 Export & Import during Unicod Conversion via SOCKET Method

Hi
We are in the process of upgrading our R/3 Enterprise to ECC 6.0. The size of the database is around 4 TeraBytes.
Can somebody help us with necessary documentation/ othe rinputs to handle R/3 Export & Import using SOCKET method? FYI we referred the SAP given doucments on the same. Any particular DOs & DO NOTs would be highly appreciated.
Thank You
Sai

Hi Rahul
regarding your 'Unicode doubt"' some ideas:
1) The Upgrade Master Guide SAP ERP 6.0 and the Master Guide SAP ERP 6.0 include introductory information. Among other, these guides reference the SAP Service Marketplace-location http://service.sap.com/unicode@sap.
2) In Unicode@SAP can you find several (content-mighty) FAQs
Conclusion from the FAQ: First of all your strategy needs to follow your busienss model (which we can not see from here):
Example. The "Upgrade to mySAP ERP 2005"-FAQ includes interesting remarks in section "DO CUSTOMERS NEED TO CONVERT TO A UNICODE-COMPLIANT ENVIRONMENT?"
"...The Unicode conversion depends on the customer situation....
... - If your organization runs a single code page system prior to the upgrade to mySAP ERP 2005, then the use of Unicode is not mandatory. ..... However, using Unicode is recommended if the system is deployed globally to facilitate interfaces and connections.
- If your organization uses Multiple Display Multiple Processing (MDMP) .... the use of Unicode is mandatory for the mySAP ERP 2005 upgrade....."
In the Technical Unicode FAQ you read under "What are the advantages of Unicode ...", that "Proper usage of JAVA is only possible with Unicode systems (for example, ESS/MSS or interfaces to Enterprise Portal). ....
=> Depending on the fact if your systems support global processes, or depending on your use of Java Applications, your strategy might need to look different
3) In particular in view of your 3rd option, I recommend you to take a look into these FAQs, if not already done.
Remark: mySAP ERP 2005 is the former name of the application, which is named SAP ERP 6.0, now
regards, and HTH, Andreas R

UNICODE CONVERSION urgent

Hi friends,
can any one send the commom errors in unicode conversion project?

Hi ,
Hope it will help you,
The Link will be helpful to you.
Re: Upgrade 4.6 to ECC - What are the responsibilites
regarding Unicode influence in Standard programs
Very good document:
http://www.doag.org/pub/docs/sig/sap/2004-03/Buhlinger_Maxi_Version.pdf
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/d37d1ad9-0b01-0010-ed9f-bc3222312dd8
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/589d18d9-0b01-0010-ac8a-8a22852061a2
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f8e316d9-0b01-0010-8e95-829a58c1511a
You need to use the transaction UCCHECK.
The report documentation is here
ABAP Unicode Scan Tool UCCHECK
You can use transaction UCCHECK to examine a Unicode program set for syntax errors without having to set the program attribute "Unicode checks active" for every individual program. From the list of Unicode syntax errors, you can go directly to the affected programs and remove the errors. It is also possible to automatically create transport requests and set the Unicode program attribute for a program set.
Some application-specific checks, which draw your attention to program points that are not Unicode-compatible, are also integrated.
Selection of Objects:
The program objects can be selected according to object name, object type, author (TADIR), package, and original system. For the Unicode syntax check, only object types for which an independent syntax check can be carried out are appropriate. The following object types are possibilities:
PROG Report
CLAS Class
FUGR Function groups
FUGX Function group (with customer include, customer area)
FUGS Function group (with customer include, SAP area)
LDBA Logical Database
CNTX Context
TYPE Type pool
INTF Interface
Only Examine Programs with Non-Activated Unicode Flag
By default, the system only displays program objects that have not yet set the Unicode attribute. If you want to use UCCHECK to process program objects that have already set the attribute, you can deactivate this option.
Only Objects with TADIR Entry
By default, the system only displays program objects with a TADIR entry. If you want to examine programs that don't have a TADIR entry, for example locally generated programs without a package, you can deactivate this option.
Exclude Packages $*
By default, the system does not display program objects that are in a local, non-transportable package. If you want to examine programs that are in such a package, you can deactivate this option.
Display Modified SAP Programs Also
By default, SAP programs are not checked in customer systems. If you also want to check SAP programs that were modified in a customer system (see transaction SE95), you can activate this option.
Maximum Number of Programs:
To avoid timeouts or unexpectedly long waiting times, the maximum number of program objects is preset to 50. If you want to examine more objects, you must increase the maximum number or run a SAMT scan (general program set processing). The latter also has the advantage that the data is stored persistently. Proceed as follows:
Call transaction SAMT
Create task with program RSUNISCAN_FINAL, subroutine SAMT_SEARCH
For further information refer to documentation for transaction SAMT.
Displaying Points that Cannot Be Analyzed Statically
If you choose this option, you get an overview of the program points, where a static check for Unicode syntax errors is not possible. This can be the case if, for example, parameters or field symbols are not typed or you are accessing a field or structure with variable length/offset. At these points the system only tests at runtime whether the code is sufficient for the stricter Unicode tests. If possible, you should assign types to the variables used, otherwise you must check runtime behavior after the Unicode attribute has been set.
To be able to differentiate between your own and foreign code (for example when using standard includes or generated includes), there is a selection option for the includes to be displayed. By default, the system excludes the standard includes of the view maintenance LSVIM* from the display, because they cause a large number of messages that are not relevant for the Unicode conversion. It is recommended that you also exclude the generated function group-specific includes of the view maintenance (usually L<function group name>F00 and L<function group name>I00) from the display.
Similarly to the process in the extended syntax check, you can hide the warning using the pseudo comment ("#EC *).
Applikation-Specific Checks
These checks indicate program points that represent a public interface but are not Unicode-compatible. Under Unicode, the corresponding interfaces change according to the referenced documentation and must be adapted appropriately.
View Maintenance
Parts of the view maintenance generated in older releases are not Unicode-compatible. The relevant parts can be regenerated with a service report.
UPLOAD/DOWNLOAD
The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.
Thanks
Jagadeesh.G

Expertise Advices on ASSM + Unicode Conversion

Hi,
I need some Expertise advice on Converting oracle Table Space to ASSM and Unicode.
Our company planning on upgrading ECC 5.0 to ECC 6.0 then we also want to do Unicode migration, but we need to know; what/when are the best practices to convert the oracle tablespace to ASSM?
I believe part of Unicode migrations we have to convert the Oracle tablespace to ASSM.
Option 1:
Is it better to convert all the tablespaces to ASSM before we do a Unicode migration? And then do the Unicode migrations?
Option 2:
Or is it better to do everything together at the same time Unicode Migrations and Tablespace conversation?
Is there are any benefits between those two options? Which one is really time saving? Option 1 or Option 2
Quick question on the side, how long would it take to convert 450 GB total data to ASSM?
Please advice on this!
Thanks in Advances
Kumar

I would suggest the following: Forget about ASSM - it will be enabled by default after your conversion, that's all I can say about ASSM in this context.
The Unicode migration itself is a really complex process, we had quite some issue to fight with. To see the whole story we were going through read that thread:
combined upgrade and unicode conversion
The topic is a bit different but I explain in-depth there, what problems we encountered, maybe this will helpful for you too.
You're right, the guides are pretty complex and the procedure and preparation is too so I would NOT do that as newbie (no offense). We had a consultant from SAP on-site while we were doing the preparation for the migration because of those many languages we had. The migration itself was then done by me after those four tests migrations I mentioned earlier.
If your system is a single codepage migration, it's not that difficult if you follow the guides provided (http://service.sap.com/unicode@sap) for your specific support package level. Just follow it step-by-step, read all the note (yes, I know, there are SO MANY).
My "best practice recommendations" are:
- use the VERY LATEST tools (kernel, R3load and dboraslib) for the export (VERY important!)
- if possible, install the latest Basis support package (SP 12 in your case) <b>before</b> you start the preparation (that is running the task of SPUMG)
- If you install the unicode instance, also use the latest tools there, latest kernel and latest R3load, you can patch the system while the database is created (there's enough time)
- if you have external systems connected, make sure, they are aware of the fact, that they are "talking" to Unicode systems after the migration (Fax-Servers, EDI and also all SAP systems such as BW, CRM, SCM or also SAP-KPRO-Servers or what else you have there)
- test, test, test, don't do the migration just theoretically
I can't provide a guide, they are highly individual depending on what modules are implemented, what external interfaces and connections to systems you have etc. etc. I could provide you with a "guide" but I'm VERY sure, there's something missing/too much and I won't be responsible for any errors/problems you will get. We did a full day of just evaluating the system, interfaces etc.
The only advise is - do a test migration, connect the system to everything you also have on production and test.
Markus

Combined Upgrade and Unicode conversion of Sap 4.6C to ECC6.0

Hello all,
my project team intends to carry out a combined upgrade and unicode conversion of an SAP ERP 4.6C system with MDMP to ECC6.0 (no enhancement package). The system is running on Oracle 10.2.
In preparation for this upgrade, I have gone through the SAP notes 928729, 54801.
We need to get a rough estimate of the entire downtime so as to alert our end users. From the CU&UC documentation in 928729, I read up note 857081. However the program in this note cannot be used to estimate the downtime as my system is < SAP netweaver 6.20.
Is there any other SAP note or tool or program that I can use to estimate the downtime for the entire CU&UC? Thanks a lot!

Hi,
Combined upgrade depend upon number of factors like database size, resources on the server and optimization. In order to get idea of how much downtime, it will take, I would suggest you to do combined upgrade and unicode conversion on sandbox system which should be the replica of your production system. And try to optimize it. From there you can get approx. downtime required.
Also, please read combined upgrade and unicode conversion guides on http://service.sap.com/unicode@sap
Thanks
Sunny

SAP R/3 4.6 C to ECC 6.0 Upgrade using CU &UC method- Unicode conversion

Basis Gurus
   I am working on upgrade from R/3 4.6C to ECC 6.0.
ECC 6.0 upgrade completed( still in non Unicode). Now I am in the process of Unicode conversion.
I have used following methods for the upgrade.
1. Combined Upgrade & Unicode conversion(CU & UC)
2. Resource minimized( as I am doing it in Sandbox).
As I understand I need to perform the DB export and Import now for the unicode conversion.
According to the Upgrade document, First I need to run Export using R3load in ECC6.0(Non unicode)
and then install Unicode system and import the same data file.
My understanding was, when I choose, Resource minimized, I need to run Export and import
in the same system.
Can you please help me , whether I need another Unicode system for import ??
Graham

Hi,
Dont get confused with upg strategy and unicode conversion.
In general Upgrade strategy (either downtime-minimized/resource minimized)
In unicode conversion you have export/import(exp/imp) of data concept
In CU&UC approach you have to do in a streach to complete migrate from old release to new realease ECC 6.00.
Using database independent (sapinst only) or Using database dependent (migration monitor or Distribution monitor)
It can be done in 2 ways.
If you dont have addtional server for unicode conversion
       1)you can either do exp on same hardware and take bakup and do import using the exp dump.
       2)Do exp on one server and prepare your target empty database on another server and complete imp of data.
Hope this is clear.
Regards,
Vamshi.

Unicode conversion in situ

Hi SCN,
I'm looking at the possibility of running a Combined Upgrade & Unicode Conversion (CUUC) in-situ; i.e. without a migration to new hardware.
However in all my years of SAP Basis projects any Unicode conversion I've seen has involved a migration to new hardware (which makes good sense as the process is the same as an OSDB migration with R3load/MigMon).
What I want to know is - has anyone ever run one in-place. I.e. keeping the same server and running the CUUC entirely inplace?
This seems logically problematic as you need a target system to import to.
I can imagine a process along these lines though...:
1. Take SAP layer offline
2. Run full backup of system
3. Export system
4. Drop database* (to make clean ready for new import)
5. Run SPUMG/SUMG/SAPINST to setup Unicode database ready to receive import...
6. ....and continue to run import into that database
7. Complete Unicode conversion process
However the big issue here for me is
(a) *dropping the live production system is far from attractive.... I'm presuming everyone would do as I've always seen and combine this with a migration to new improved hardware, so that a backout to the old system is simple
(b) I'm not sure at what point with the SAP tools (SPUMG/SUMG/SAPINST) this process would become convoluted with it all being in-situ on the same box. I.e. I'm not sure if it's something the SAP tools are really designed to cater for.
Any input/discussion on these points would be very welcome.
Regards, doonan_79

FYI Community. Feeling after reading and research is to use a temorary server to import unicode converted system data into; then swing disks back to the original host. Making all required hostname updates during the process.
Allowing for parallel export/import, but going back to the original configured host to complete the process.

Some character display incorrect after unicode conversion

Dear Experts,
Currently we upgrade our SAP system from 4.6B NU to ECC6.0 UN.
in 4.6B system we had implemented Simple Chinese and French language package to the system. after upgrade to ECC6.0 no-unicode system. we perform a MDMP unicode conversion.currently system running with ECC6.0 unicode interface with language 1EFD. SUMG releated tasks had been finished. Chinese and French language checked OK in ECC6 UN system.
Our issue is. in the past time. some Spanish local end user typing some spanish character in some master date field when they login in 4.6B GUI choice english as login language.these kind of spanish characters could not display correct in current unicode environment.
could you please given us some suggestion for how to fix this issue.
I also sent this message in the Netweaver administrator forums with below links.
Spanish display incorrect after unicode conversion

Hello,
I doubt that the data shown by you in the link was caused by Spanish users logged on in EN.
I think this was rather caused by utf-8 data uploaded into the Non-Unicode system.
In this case, you need to repair the according texts manually, I do not know any automatic repair.
Best regards,
Nils Buerckel
SAP AG

Unicode Conversion : Import Error in ABAP SAPCLUST Error

Hi
I am doing the unicode conversion ..
The export of the database is successful.. But during the import it is giving an error.
Export is done as per note 552464 (Code Page 4103)
Platform is windows server 2003 / Oracle 10.2
Loading of 'SAPCLUST' import package: ERROR
(GSI) INFO: vname    = "ORACLE                          "
(GSI) INFO: hostname = "CTSINTCOSNW5                                                    "
(GSI) INFO: sysname = "Windows NT"
(GSI) INFO: nodename = "CTSINTCOSNW5"
(GSI) INFO: release = "5.2"
(GSI) INFO: version = "3790 Service Pack 1"
(GSI) INFO: machine = "8x Intel 801586 (Mod 4 Step 9)"
(DB) INFO: CLU4 deleted/truncated #20070301165425
myCluster (63.7.Imp): 2113: inconsistent field names (source) : physical field K1N05 appears as logic K1N5.
myCluster (63.7.Imp): 2114: further investigation recommended.
myCluster (63.7.Imp): 1952: error when checking key field consistency for logic table TACOPC    .
myCluster (63.7.Imp): 1955: logic table is canonical.
myCluster (63.7.Imp): 1958: received return code 2 from c3_uc_check_key_field_descr_consistency.
myCluster (63.7.Imp): 1252: unable to retrieve nametab info for logic table TACOPC    .
myCluster (63.7.Imp): 8096: unable to acquire nametab info for logic table TACOPC    .
myCluster (63.7.Imp): 2835: failed to convert cluster data of cluster item.
myCluster: CLU4       *00001*
myCluster (63.7.Imp): 320: error during conversion of cluster item.
myCluster (63.7.Imp): 323: affected physical table is CLU4.
(CNV) ERROR: code page conversion failed
             rc = 2
.--============--
RSCP - Error
`----
(DB) INFO: disconnected from DB
D:\usr\sap\ABU\SYS\exe\uc\NTI386\R3load.exe: job finished with 1 error(s)
D:\usr\sap\ABU\SYS\exe\uc\NTI386\R3load.exe: END OF LOG: 20070301165425
Can any one help please ?
Thanks in advance

hi,
could you please have a look to SAP Note 902817 - Inconsistencies in cluster tables (log vs phys field name)
Cheers,
-Sunil

UNICODE conversion of Siebel Database- Impact on interface

Similar Messages

Maybe you are looking for