Unicode/non-unicode database

Hi,
I have two Oracle 8.1.7 databases : an unicode database, and a non-unicode database.
Can I export schema from non-unicode database to unicode database without problem ? What is the real impact ?
Thank you in advance for your help,
Nicolas.

Depending on the data that you have in your non-unicode database, potentially data expansions or data loss may occur.
Data expansions
For example, a 1 byte character in a VARCHAR2(1) column may expand to 2 bytes or 3 bytes in a Unicode (UTF8) database; hence you may need to re-define you scheme prior to importing the data into your new Unicode database.
Data Loss
This happens only if you have invalid characters inside your non-unicode database. For example, you may have some 8-bit non-ASCII characters inside your US7ASCII database, during export these characters will be converted to some replacement characters (?).
However you can use the character set scanner (csscan) to scan your source database to detect both of the above scenarios. Please visit the Globalization Support section of OTN for more info - http://technet.oracle.com/tech/globalization/content.html
Regards
Nat

Similar Messages

How to check for Unicode/Non-Unicode SAP?

Hi All,
Please let me know how can I check whether an SAP system is a Unicode/Non-Unicode from SAP GUI?
Thanks in advance,
Adarsh

Hi,
You can check under menu :
System -> Status -> SAP System Data -> Unicode System -> Yes/ No

Upgrade 4.6C to ECC 6.0; Unicode - non-Unicode -- Unicode

Hi,
My client has a R/3 4.6c UNICODE, he wants to upgrade to ECC6.0 UNICODE.
According to a SAP document, to upgrade, I upgrade directly to ECC 6.0 NON_UNICODE then convert the system to ECC 6.0 UNICODE.
I'm wonder why Unicode -> non-Unicode --> Unicode.
Regards,
Toan Do

"4.6C is not a unicode system ,ecc6.0 is an unicode system."
Actually, ECC 6.0 only has to be unicode if you are a new installation. If you are upgrading from a non-unicode system, you can upgrade to a non-unicode ECC 6.0 system, this is fully supported by SAP.
However, it is recommended that you perform the upgrade and unicode conversion at the same time. SAP is going to force us to unicod some day anyway.
We have just completed a technical upgrade from 4.7 to ECC 6 non-unicode, and now we are looking at a unicode conversion project. It would have added time to the original upgrade project, but it would have been worth it.
T

RFC Destination - Unicode / non - Unicode behavior

Hi All,
In our current production system the RFC destination from R3 to Xi is non-unicode.We have currently 300 Interfaces running using this RFC destination in production.
In few upcoming requirements for some 15 Interfaces some special characters will come from R3 to Xi system.In this case we need a unicode RFC Destination.
I have a query here , can i go ahead and change the existing RFC destination to Unicode or is it suggestible to create a new RFC destination only for these 15 Interfaces?
Need expert advice on this?
<<Text removed>>
Regards,
RK
Edited by: Matt on Oct 5, 2011 9:38 AM

Hello,
The Non-Unicode Single code page systems are supported by SAP for older applications for historical reasons - unicode was not available when they were released. These systems are restricted to only processing characters from their specific code page. This means their can be restrictions if they need to support language combinations that span multiple code pages - basically it is not possible. In addition some languages are not fully available at all for single code page systems like Thai. In addition the Euro symbol is not available.
Unicode is the future for all applications - SAP or otherwise. The significance at the moment is where customers who needs to convert to unicode to support additional business requirements like additional languages. Converting a system, although a simple process is not a trivial process in terms of time and resources.
So u can go ahead and change the existing RFC destination to Unicode .it will not create any prob. for other interfaces which are using non unicode setting.
Regards
Monica

Passing chinese character from RFC call between unicode & non unicode syst.

Hi Experts,
I am making a RFC call from an ABAP in non unicode system to a Function module in Unicode system and filling the itab fields in ABAP by using move statement and using offset in order to populate amount fields correctly from flat structure tables returned by function module. But i am facing problem in getting chinese characters correctly in return from the Remote Function Module.
        CALL FUNCTION 'ZFXX_GET_CLR_OI'
          STARTING NEW TASK W_TASKNAME
          DESTINATION S_RFCDES-LOW
          PERFORMING F3100_GET_RFC_DATA ON END OF TASK
          EXPORTING
            P_WAERS               = P_WAERS             "Screen Curr
            P_AUGDT               = P_AUGDT             "Clearing date
            P_BUKRS               = P_BUKRS             "Comp Code
          TABLES
            T_SEL_TABLE           = T_SEL_TABLE
            T_OUTPUT              = T_MCDATA
            T_ERRORS              = T_EMCDATA
          EXCEPTIONS
            COMMUNICATION_FAILURE = 1
            SYSTEM_FAILURE        = 2
            OTHERS                = 3.
       MOVE : t_mcdata1-line+0(32)   TO t_succs-awsys,
               t_mcdata1-line+32(4)   TO t_succs-bukrs,
               t_mcdata1-line+36(10) TO t_succs-belnr,
               t_mcdata1-line+46(4)   TO t_succs-gjahr,
               t_mcdata1-line+50(1)   TO t_succs-shkzg,
               t_mcdata1-line+51(2)   TO t_succs-bschl,
               t_mcdata1-line+53(4)   TO t_succs-gsber,
               t_mcdata1-line+57(16) TO t_succs-dmbtr,
               t_mcdata1-line+73(16) TO t_succs-wrbtr,
               t_mcdata1-line+89(5)   TO t_succs-pswsl,
               t_mcdata1-line+94(6)   TO t_succs-vbund,
               t_mcdata1-line+100(10) TO t_succs-hkont,
               t_mcdata1-line+110(10) TO t_succs-prctr,
               t_mcdata1-line+120(16) TO t_succs-dmbe2,
               t_mcdata1-line+136(20) TO t_succs-txt20.
        APPEND t_succs.
Can anybody suggest or advice me on it ? Any help or suggestion would be appreciated.
Thanks in advance,
Akash

.

How to check whether NW2004s-Installation is unicode/non-unicode

Hi,
I have to check, whether our NW2004s-Installation (ERP 2005) is a unicode-installation or a non-unicode.
How can I check it? - the sap-admin I can ask is on holiday.
Thanks
Wolfgang

You can go to the Backend and click on System -> Status, and under SAP System Data you should be able to see Unicode System (Yes or No)...
Hope this help!
Regards
Juan Reyes

Unicode -- non-unicode transports

Hello!
Is it possible to exchange transports between unicode and non-unicode systems, such as client export-imports, change requests etc?
Thanks!
Kind regards,
Igor Barbaric

Hello,
Have a look at note 638357.
Pmc

Unicode Non Unicode

Hi Experts
I have installaed a ECC 6.0 ABAP+ JAVA unicode system. Now for soem reason my management wants to move to a Non-Unicode version.
Is there any way we can make unicode to Non-Unicode conversion or I have to go for a fresh install and start all work fron scratch.

Hello Raj,
As you can see above there is no method to move your system to a Non Unicode System from a Unicode system.
In addition to this, i would point out that even with a non unicode system your java stack will always have to
be unicode even your your abap stack is not.
Kind Regards,
David

UNICODE / non-UNICODE switch for interfaces ?

Hello,
after having migrated to UNICODE we face problems with file interfaces.
Obviously, the output files are now in UNICODE format, because the other systems are no longer able to read them.
How do we switch back the output format to single-byte modus, so the file format stays the same as before ?
Thanks, Ruediger Bergmann

Hello Rüdiger
Perhaps the Weblog of Ulrich Brink about
may be helpful to overcome your problem.
Regards
Uwe

Unicode and non-unicode string data types Issue with 2008 SSIS Package

Hi All,
I am converting a 2005 SSIS Package to 2008. I have a task which has SQL Server as the source and Oracle as the destination. I copy the data from a SQL server view with a field nvarchar(10) to a field of a oracle table varchar(10). The package executes fine
on my local when i use the data transformation task to convert to DT_STR. But when I deploy the dtsx file on the server and try to run from an SQL Job Agent it gives me the unicode and non-unicode string data types error for the field. I have checked the registry
settings and its the same in my local and the server. Tried both the data conversion task and Derived Column task but with no luck. Pls suggest me what changes are required in my package to run it from the SQL Agent Job.
Thanks.

What is Unicode and non Unicode data formats
Unicode :
A Unicode character takes more bytes to store the data in the database. As we all know, many global industries wants to increase their business worldwide and grow at the same time, they would want to widen their business by providing
services to the customers worldwide by supporting different languages like Chinese, Japanese, Korean and Arabic. Many websites these days are supporting international languages to do their business and to attract more and more customers and that makes life
easier for both the parties.
To store the customer data into the database the database must support a mechanism to store the international characters, storing these characters is not easy, and many database vendors have to revised their strategies and come
up with new mechanisms to support or to store these international characters in the database. Some of the big vendors like Oracle, Microsoft, IBM and other database vendors started providing the international character support so that the data can be stored
and retrieved accordingly to avoid any hiccups while doing business with the international customers.
The difference in storing character data between Unicode and non-Unicode depends on whether non-Unicode data is stored by using double-byte character sets. All non-East Asian languages and the Thai language store non-Unicode characters
in single bytes. Therefore, storing these languages as Unicode uses two times the space that is used specifying a non-Unicode code page. On the other hand, the non-Unicode code pages of many other Asian languages specify character storage in double-byte character
sets (DBCS). Therefore, for these languages, there is almost no difference in storage between non-Unicode and Unicode.
Encoding Formats:
Some of the common encoding formats for Unicode are UCS-2, UTF-8, UTF-16, UTF-32 have been made available by database vendors to their customers. For SQL Server 7.0 and higher versions Microsoft uses the encoding format UCS-2 to store the UTF-8 data. Under
this mechanism, all Unicode characters are stored by using 2 bytes.
Unicode data can be encoded in many different ways. UCS-2 and UTF-8 are two common ways to store bit patterns that represent Unicode characters. Microsoft Windows NT, SQL Server, Java, COM, and the SQL Server ODBC driver and OLEDB
provider all internally represent Unicode data as UCS-2.
The options for using SQL Server 7.0 or SQL Server 2000 as a backend server for an application that sends and receives Unicode data that is encoded as UTF-8 include:
For example, if your business is using a website supporting ASP pages, then this is what happens:
If your application uses Active Server Pages (ASP) and you are using Internet Information Server (IIS) 5.0 and Microsoft Windows 2000, you can add "<% Session.Codepage=65001 %>" to your server-side ASP script.
This instructs IIS to convert all dynamically generated strings (example: Response.Write) from UCS-2 to UTF-8 automatically before sending them to the client.
If you do not want to enable sessions, you can alternatively use the server-side directive "<%@ CodePage=65001 %>".
Any UTF-8 data sent from the client to the server via GET or POST is also converted to UCS-2 automatically. The Session.Codepage property is the recommended method to handle UTF-8 data within a web application. This Codepage
setting is not available on IIS 4.0 and Windows NT 4.0.
Sorting and other operations :
The effect of Unicode data on performance is complicated by a variety of factors that include the following:
1. The difference between Unicode sorting rules and non-Unicode sorting rules
2. The difference between sorting double-byte and single-byte characters
3. Code page conversion between client and server
Performing operations like >, <, ORDER BY are resource intensive and will be difficult to get correct results if the codepage conversion between client and server is not available.
Sorting lots of Unicode data can be slower than non-Unicode data, because the data is stored in double bytes. On the other hand, sorting Asian characters in Unicode is faster than sorting Asian DBCS data in a specific code page,
because DBCS data is actually a mixture of single-byte and double-byte widths, while Unicode characters are fixed-width.
Non-Unicode :
Non Unicode is exactly opposite to Unicode. Using non Unicode it is easy to store languages like ‘English’ but not other Asian languages that need more bits to store correctly otherwise truncation will occur.
Now, let’s see some of the advantages of not storing the data in Unicode format:
1. It takes less space to store the data in the database hence we will save lot of hard disk space.
2. Moving of database files from one server to other takes less time.
3. Backup and restore of the database makes huge impact and it is good for DBA’s that it takes less time
Non-Unicode vs. Unicode Data Types: Comparison Chart
The primary difference between unicode and non-Unicode data types is the ability of Unicode to easily handle the storage of foreign language characters which also requires more storage space.
Non-Unicode
Unicode
(char, varchar, text)
(nchar, nvarchar, ntext)
Stores data in fixed or variable length
Same as non-Unicode
char: data is padded with blanks to fill the field size. For example, if a char(10) field contains 5 characters the system will pad it with 5 blanks
nchar: same as char
varchar: stores actual value and does not pad with blanks
nvarchar: same as varchar
requires 1 byte of storage
requires 2 bytes of storage
char and varchar: can store up to 8000 characters
nchar and nvarchar: can store up to 4000 characters
Best suited for US English: "One problem with data types that use 1 byte to encode each character is that the data type can only represent 256 different characters. This forces multiple
encoding specifications (or code pages) for different alphabets such as European alphabets, which are relatively small. It is also impossible to handle systems such as the Japanese Kanji or Korean Hangul alphabets that have thousands of characters."<sup>1</sup>
Best suited for systems that need to support at least one foreign language: "The Unicode specification defines a single encoding scheme for most characters widely used in businesses around the world.
All computers consistently translate the bit patterns in Unicode data into characters using the single Unicode specification. This ensures that the same bit pattern is always converted to the same character on all computers. Data can be freely transferred
from one database or computer to another without concern that the receiving system will translate the bit patterns into characters incorrectly.
https://irfansworld.wordpress.com/2011/01/25/what-is-unicode-and-non-unicode-data-formats/
Thanks Shiven:) If Answer is Helpful, Please Vote

Regarding non-unicode to unicode conversion in mapping

In our project we have Pi system which is installed as unicode system.
But the SAP systems at the sender side is unicode and most of them are non-unicode systems.
We have a doubt regarding the challenges that we need to face in PI mapping with reference to unicode and non unicode conversion.
Is it possible for us to Map the RFCs of non-unicode SAP system at sender side with the help of graphical mapping?
Any conversion we need to do?
Thanks & Regards,
sasi
Edited by: sasitharan on Jan 6, 2009 4:25 PM

Thanks a lot for your replys.
In our customer lanscape they have following SAP R/3 vsesions 4.0B,4.5B.4.6B,4.6C,ECC 5.0,ECC 6.0
so how this unicode , non unicode settings varies with respect to versions?
Is it resembles same with respect to all the version?
Thanks & Regards,
Sasi

Can we UseECC6 non Unicode with SRM7.0 Unicode system

Hi SRM Gurus,
Can we use ECC6.0 non unicode system with SRM7.0 Unicode system as a backend?
I am searching for the information regarding the compatability and connectivity between Unicode and nonunicode systems.
Can some please do let me know the web links related to my post or Please do let me know the Possibility for using ECC6.0 Non-Unicode with the SRM7.0 Unicode.
Regards,
Srini

Hi,
RFC communication takes care Unicode conversion. Question is how many languages are used in ERP 6.0. Non-Unicode -> Unicode should not be a problem but Unicode -> Non-Unicode is question.
Is it single codepage system or old MDMP system?
Regards,
Masa

Unicode or non-unicode

Hi,
any query or way to know if a peoplesoft system installation is Unicode or Non-unicode ?
Thank you.

You can query from PSSTATUS
select ownerid, decode(UNICODE_ENABLED,1,'Unicode','Non - Unicode') UNICODE_ENABLED from PSSTATUS;

Double byte language i.e Japanese or Chinese text in non Unicode System

Hi,
I have translated text into Chinese and Japanese in a Unicode system and want to move it into a non Unicode system. Would Chinese/Japanese characters display correctly in a non Unicode system when moved from Unicode system. I am doing translation in ECC60 or SAP 4.7 Unicode system and moving to SAP 4.7 non Unicode system.
Thanks
Balakrishna

Hi Balakrishna,
in general the transport between Unicode and Non-Unicode systems is supported.
However there are restrictions, which are outlined in SAP note 638357.
In your case it is a prerequisite that the objects to be transported are language dependent (text lang. flag is set on the language key - see SAP note 480671) and the languages are properly setup in the target systems.
For double byte data there is a specific issue when transferring data from Unicode to Non-Unicode:
In a Non-Unicode system, one double-byte character needs two bytes, therefore e.g. in a 10 char field, 5 double byte chars are fitting. In a Unicode system, you can insert 10 double-byte chars in a 10 char field. Hence there is a risk of truncating characters in case of Unicode --> Non-Unicode communication.
Please also have a look at SAP notes 1322715 and 745030.
Best regards,
Nils

Importing non-unicode data into unicode 10gR2 database

Hi:
I will have to import non-unicode data into unicode 10gR2 database. The systems the data is coming from are the following: CODA, Timberline, COMMS, CMS, LIMS. These are all RDBMS, sql-enabled systems. We are talking about pretty big amounts of data (a couple hundred GB combined).
Did anybody go through a similar exersize?
I know I'll have to setup nls_length_semantics to CHAR.
What other recommendations could you guys give?
TIA,
Greg

I think "nls_length_semantics" isn't mandatory at this point, and you must extract a little quantity of information from every source and do some probes injecting them into the Oracle10g database.

Unicode/non-unicode database

Similar Messages

Maybe you are looking for