Dear Admin,
I am using Oracle 8i and Form 6. How we can use Urdu for input and output of data using oracle 8i and form 6 or 6i. If you have an idea about it please guide me. An early response will highly be appreciated.
How can we use Urdu in Oracle
-
ahmadbilal
- Posts: 615
- Joined: Mon Sep 18, 2006 1:32 am
- Location: United Arab Emirates
- Contact:
you can use ocx control for data input in forms if Wroking On AS env.
you can also simply change the windows default Fonts To urdu and Change Oracle Characterset to W9851 Or Something like that(Charcter Set oracle Recomande For Arabic)
You may Face Problem In Reports Like Sorting of Data Formation Of Data etc
you can also simply change the windows default Fonts To urdu and Change Oracle Characterset to W9851 Or Something like that(Charcter Set oracle Recomande For Arabic)
You may Face Problem In Reports Like Sorting of Data Formation Of Data etc
-
ahmadbilal
- Posts: 615
- Joined: Mon Sep 18, 2006 1:32 am
- Location: United Arab Emirates
- Contact:
This is Metalink Article.I will try To Send you The Form As Well
Changing the Database Character Set - an extended overview
Doc ID: Note:257736.1 Type: BULLETIN
Last Revision Date: 04-JAN-2006 Status: PUBLISHED
Introduction
============
Note 225912.1 Changing the Database Character Set - a short overview
gives a short overview of the basics of changing a character set.
This article aims to give more in-depth overview of possibilities to change the
database character set, and points to notes that are specific to the methods
described here. If you use this note as a guide you're sure to find the correct
information for your particular circumstances.
Please make sure that you have a good understanding of how oracle deals with
character set conversion before going ahead with this, start with going trough
the following note before changing the character set of you database:
Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?)
The database character set & code points
========================================
Changing the database character set can have a lot of consequences that should
be understood before starting with it. The character set of a database defines
how characters are stored in the database and therefore you are limited to
storing just the characters defined in that character set.
A character set is basicaly just a list of characters with a assigned
"character number", or code point. For example in most character sets the
"space" is defined as 'character number 32' and the letter "A" is defined as
'character numer 65'. We call these character numbers in a character set
"code points".
If you change character sets there is a possibility that characters that you
currently use are not defined in the new character set and therefore you could
'corrupt' your data. The following note gives a good way of viewing the
characters that are defined in a character set (and their code points):
Note 223706.1 Using Locale Builder to view the definition of character sets.
You can check what what code points are physically stored in your database at
this moment by using the dump command , see these notes for more details:
Note 13854.1 Dump SQL Command for NLS Debugging
Note 69518.1 Determining the code point for UTF8 characters
Choosing a new database character set
=====================================
Oracle believes that for the majority of customers a unicode character set
is the best choice.
If you choose any other character set then please be advised of the following:
Note 306411.1 Character Set Consolidation for Oracle Database 11
Using "Oracle Applications"
===========================
If you use Oracle Applications the basic task of running the character set
scanner explained in this note are the same, so please continue to read this
note to get a full understanding of the migration options. However there are
some additional considerations so please see the following note for a complete
overview of changing the character set in an Applications Database:
Note 124721.1 Migrating an Applications Installation to a New Character Set
Preparation
===========
The first step in the process of changing the database character set is running
the character set scanner (csscan) to check how the data will cope with the
character set change. Using this you will find the data that can not be stored
in the new character set. This can be either due to the fact that the new
character set does not describe the characters you currently store, or it can
be due to size restrictions. The following note explains how to use the
character set scanner and gives some examples:
Note 123670.1 Use Scanner Utility before Altering the Database Character Set
The character set scanner reports the status of each table as one of these 3:
CHANGELESS - the data would be stored in exactly the same way in the new
character set.
CONVERTIBLE - the data can be stored using the new character set without
problems but different code points are used so it needs to be converted.
EXCEPTIONAL - These are the tables/rows with problems that need to be tackled
before going ahead with the conversion
When you've changed the data in the original database and csscan only reports
tables to be CHANGELESS or CONVERTIBLE it's time to move on to changing
the database character set.
Important warning:
When using the Character set scanner you could find out that your data is
stored completely incorrectly. For example you might have stored Arabic data
in a WE8ISO8859P1 database (due to incorrect NLS_LANG settings on the client).
This is typicaly showed as EXCEPTIONAL data found.
In that case please see the following note, which explains how to recover from
these problems: Note 225938.1 Database Character Set Healthcheck
Once the data is stored correctly you then have to start over and go through
the steps of this note again to change the character set.
For example you might have a database that currently has the US7ASCII character
set and you might want to change it to AL32UTF8. You might come to the
conclusion that you actually have WE8MSWIN1252 codes (the character set of
Western Windows) stored in your current US7ASCII database. You then need to
first follow the mentioned Note 225938.1 to change the database to the
correct character set. After that you can restart with this note to move from
there to the desired character set.
Changing the database character set
===================================
After having asserted the data is not going to give us problems by using csscan
we now come to the real work of changing the character set. Since Oracle 8.0
there are 2 ways to do this:
The simplest way is to use the "ALTER DATABASE CHARACTER SET" command but that
is not always possible. Something that will always work is to export the
current database, then create a new database with the new character set and
import the data into that database. Sometimes a combination of the 2 methods
can be used. We will describe the methods further:
1. using the ALTER DATABASE CHARACTER SET command
-------------------------------------------------
This command was introduced in Oracle8. The statement does not actually convert
any characters in the database. It simply updates all the places in the
database where the character set information is stored. That means that you
can only use this statement if the new character set is a superset of the old
character set. We make the distinction between a binary -or TRUE- superset and
a 'normal' superset. For example lets take character set A and B. Character set
A is a binary superset of character set B if A describes exactly the same
characters and used the same codepoint for those characters as B does. On top
of that it probably also has some more characters characters at codepoints that
are left free by character set B - otherwise they would be 100% the same set.
If this is the case then csscan would have flagged up a CHANGELESS conversion
in the csscan output and this method will work fine.
It is also possible for a character set to contain the same (and more)
characters as another character set but store those characters at different
code points. Although this is still a logical superset it is not a binary
superset. Csscan would flag those characters up as CONVERTIBLE and we need
another method of changing the character set. An example of this is (AL32)UTF8,
which is a Unicode character set. It easily contains all the characters of, for
example WE8ISO8859P15. However, it defines a lot of those characters at
different code points. Therefore UTF8 is not classed as a binary superset of
WE8ISO8859P15. The following note gives an overview of all the superset/subset
combinations that exists:
Note 119164.1 Changing Database Character Set - Valid Superset Definitions
So, if you indeed are changing to a superset and csscan showed all your data
as CHANGELESS you can use the ALTER DATABASE CHARACTER SET command. See the
following note for a detailed description of how to do this:
Note 66320.1 Changing the Database Character Set or the Database National Character Set
2. Using export/import
----------------------
A method that will always work is using export/import. You use this method if
the csscan has marked your data CONVERTIBLE. Be aware that using this method
you will not receive an error when you move to an incompatible character set
(using method 1 you will get errors in that case). If characters show up as
"EXCEPTIONAL" in the csscan output you can still press ahead with export/import.
Characters that do not exist in the new character set are then replaced by a
so-called replacement character. It is not advisable to rely on this, it is a
better to make the choices yourself by changing data that shows up as
EXCEPTIONAL before the export.
Also rows are flagged in csscan because the data in the new database will be
expanded and will not fit in the allocated storage space. If you press ahead
with the exp/imp they will simply receive a error om import (ORA-1401) and will
not be imported.
When you change character sets through export/import you could potentially go
through 3 different conversions. This is explained (among other things) in the
following note:
Note 15095.1 Export/Import and NLS Considerations
We obviously want to keep the number of conversions down to just 1 instead of 3
because there is less chance of problems that way. The easiest way to achieve
that is to keep the export character set (the setting in NLS_LANG when the
export is done) and the import session character set (the setting in NLS_LANG
when the import is done) the same as the character set in the original
database. That means that no conversion takes place on export and no conversion
takes place inside the import session. The only conversion that takes place is
from the import session (which by that point still has the original data) to
the new database.
So, if you only have CONVERTIBLE and CHANGELESS data then:
1) Export the source database with the NLS_LANG set to the character set of the
source (OLD) database.
( select * from nls_database_parameters where parameter = 'NLS_CHARACTERSET'; )
2) Create a NEW database with the NEW database characterset you want to use.
3) Import the export file with the NLS_LANG set to the character set of the
source (OLD) database.
4) The character set conversion will be done at the moment that the import
executable inserts the data into the new database.
5) Backup the new database.
3. Using a combination of ALTER DATABASE CHARACTER SET and export/import
------------------------------------------------------------------------
In some cases you might find that csscan tells you that most of your data is
CHANGELESS but only one (or a small number) of your tables is CONVERTABLE.
In that case you would still have to use export/import. If the size of the
database is particularly large and using export/import will cause too much
down time you could follow this method:
a) Export the data from the tables that come out as CONVERTABLE.
b) Truncate or drop those tables.
c) Now you have a database with only CHANGELESS data. Because the character set
is not classed as a subset of the new character set you cannot use the normal
form of the ALTER DATABASE CHARACTER SET command. The command usually simply
checks if the new character set is a superset of the old character set, it does
not check the actual data. In order to force the change please contact Oracle
Support. Provide them with the output of csscan showing all data is classed as
CHANGELESS and they will then assist you in forcing the character set change.
d) Now that the character set has changed we can simply import the data
exported in step (a). The import will convert that data so that it gets stored
in the correct way for this character set.
After changing the database character set
=========================================
Remember that changing the database character set only changes the way
characters are stored on the database. This should NOT have any effect on the
clients and you should not have to change the NLS_LANG for example. The
NLS_LANG on the clients should simply reflect the setup of that machine.
For more general information on setting up NLS_LANG and how client-server
conversion works please see the following notes:
Note 179133.1 The correct NLS_LANG in a Windows Environment
Note 264157.1How to set correctly NLS_LANG on Unix Environments
Note 229786.1 NLS_LANG and webservers explained.
Further reading
===============
Note 237593.1 Problems connecting to AL32UTF8 databases from older versions (8i and lower)
For further NLS / Globalization information you may start here:
Note 267942.1 Globalization Technology (NLS) Knowledge Browser .
Note 60134.1 Globalization (NLS) - Frequently Asked Questions
.
Changing the Database Character Set - an extended overview
Doc ID: Note:257736.1 Type: BULLETIN
Last Revision Date: 04-JAN-2006 Status: PUBLISHED
Introduction
============
Note 225912.1 Changing the Database Character Set - a short overview
gives a short overview of the basics of changing a character set.
This article aims to give more in-depth overview of possibilities to change the
database character set, and points to notes that are specific to the methods
described here. If you use this note as a guide you're sure to find the correct
information for your particular circumstances.
Please make sure that you have a good understanding of how oracle deals with
character set conversion before going ahead with this, start with going trough
the following note before changing the character set of you database:
Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?)
The database character set & code points
========================================
Changing the database character set can have a lot of consequences that should
be understood before starting with it. The character set of a database defines
how characters are stored in the database and therefore you are limited to
storing just the characters defined in that character set.
A character set is basicaly just a list of characters with a assigned
"character number", or code point. For example in most character sets the
"space" is defined as 'character number 32' and the letter "A" is defined as
'character numer 65'. We call these character numbers in a character set
"code points".
If you change character sets there is a possibility that characters that you
currently use are not defined in the new character set and therefore you could
'corrupt' your data. The following note gives a good way of viewing the
characters that are defined in a character set (and their code points):
Note 223706.1 Using Locale Builder to view the definition of character sets.
You can check what what code points are physically stored in your database at
this moment by using the dump command , see these notes for more details:
Note 13854.1 Dump SQL Command for NLS Debugging
Note 69518.1 Determining the code point for UTF8 characters
Choosing a new database character set
=====================================
Oracle believes that for the majority of customers a unicode character set
is the best choice.
If you choose any other character set then please be advised of the following:
Note 306411.1 Character Set Consolidation for Oracle Database 11
Using "Oracle Applications"
===========================
If you use Oracle Applications the basic task of running the character set
scanner explained in this note are the same, so please continue to read this
note to get a full understanding of the migration options. However there are
some additional considerations so please see the following note for a complete
overview of changing the character set in an Applications Database:
Note 124721.1 Migrating an Applications Installation to a New Character Set
Preparation
===========
The first step in the process of changing the database character set is running
the character set scanner (csscan) to check how the data will cope with the
character set change. Using this you will find the data that can not be stored
in the new character set. This can be either due to the fact that the new
character set does not describe the characters you currently store, or it can
be due to size restrictions. The following note explains how to use the
character set scanner and gives some examples:
Note 123670.1 Use Scanner Utility before Altering the Database Character Set
The character set scanner reports the status of each table as one of these 3:
CHANGELESS - the data would be stored in exactly the same way in the new
character set.
CONVERTIBLE - the data can be stored using the new character set without
problems but different code points are used so it needs to be converted.
EXCEPTIONAL - These are the tables/rows with problems that need to be tackled
before going ahead with the conversion
When you've changed the data in the original database and csscan only reports
tables to be CHANGELESS or CONVERTIBLE it's time to move on to changing
the database character set.
Important warning:
When using the Character set scanner you could find out that your data is
stored completely incorrectly. For example you might have stored Arabic data
in a WE8ISO8859P1 database (due to incorrect NLS_LANG settings on the client).
This is typicaly showed as EXCEPTIONAL data found.
In that case please see the following note, which explains how to recover from
these problems: Note 225938.1 Database Character Set Healthcheck
Once the data is stored correctly you then have to start over and go through
the steps of this note again to change the character set.
For example you might have a database that currently has the US7ASCII character
set and you might want to change it to AL32UTF8. You might come to the
conclusion that you actually have WE8MSWIN1252 codes (the character set of
Western Windows) stored in your current US7ASCII database. You then need to
first follow the mentioned Note 225938.1 to change the database to the
correct character set. After that you can restart with this note to move from
there to the desired character set.
Changing the database character set
===================================
After having asserted the data is not going to give us problems by using csscan
we now come to the real work of changing the character set. Since Oracle 8.0
there are 2 ways to do this:
The simplest way is to use the "ALTER DATABASE CHARACTER SET" command but that
is not always possible. Something that will always work is to export the
current database, then create a new database with the new character set and
import the data into that database. Sometimes a combination of the 2 methods
can be used. We will describe the methods further:
1. using the ALTER DATABASE CHARACTER SET command
-------------------------------------------------
This command was introduced in Oracle8. The statement does not actually convert
any characters in the database. It simply updates all the places in the
database where the character set information is stored. That means that you
can only use this statement if the new character set is a superset of the old
character set. We make the distinction between a binary -or TRUE- superset and
a 'normal' superset. For example lets take character set A and B. Character set
A is a binary superset of character set B if A describes exactly the same
characters and used the same codepoint for those characters as B does. On top
of that it probably also has some more characters characters at codepoints that
are left free by character set B - otherwise they would be 100% the same set.
If this is the case then csscan would have flagged up a CHANGELESS conversion
in the csscan output and this method will work fine.
It is also possible for a character set to contain the same (and more)
characters as another character set but store those characters at different
code points. Although this is still a logical superset it is not a binary
superset. Csscan would flag those characters up as CONVERTIBLE and we need
another method of changing the character set. An example of this is (AL32)UTF8,
which is a Unicode character set. It easily contains all the characters of, for
example WE8ISO8859P15. However, it defines a lot of those characters at
different code points. Therefore UTF8 is not classed as a binary superset of
WE8ISO8859P15. The following note gives an overview of all the superset/subset
combinations that exists:
Note 119164.1 Changing Database Character Set - Valid Superset Definitions
So, if you indeed are changing to a superset and csscan showed all your data
as CHANGELESS you can use the ALTER DATABASE CHARACTER SET command. See the
following note for a detailed description of how to do this:
Note 66320.1 Changing the Database Character Set or the Database National Character Set
2. Using export/import
----------------------
A method that will always work is using export/import. You use this method if
the csscan has marked your data CONVERTIBLE. Be aware that using this method
you will not receive an error when you move to an incompatible character set
(using method 1 you will get errors in that case). If characters show up as
"EXCEPTIONAL" in the csscan output you can still press ahead with export/import.
Characters that do not exist in the new character set are then replaced by a
so-called replacement character. It is not advisable to rely on this, it is a
better to make the choices yourself by changing data that shows up as
EXCEPTIONAL before the export.
Also rows are flagged in csscan because the data in the new database will be
expanded and will not fit in the allocated storage space. If you press ahead
with the exp/imp they will simply receive a error om import (ORA-1401) and will
not be imported.
When you change character sets through export/import you could potentially go
through 3 different conversions. This is explained (among other things) in the
following note:
Note 15095.1 Export/Import and NLS Considerations
We obviously want to keep the number of conversions down to just 1 instead of 3
because there is less chance of problems that way. The easiest way to achieve
that is to keep the export character set (the setting in NLS_LANG when the
export is done) and the import session character set (the setting in NLS_LANG
when the import is done) the same as the character set in the original
database. That means that no conversion takes place on export and no conversion
takes place inside the import session. The only conversion that takes place is
from the import session (which by that point still has the original data) to
the new database.
So, if you only have CONVERTIBLE and CHANGELESS data then:
1) Export the source database with the NLS_LANG set to the character set of the
source (OLD) database.
( select * from nls_database_parameters where parameter = 'NLS_CHARACTERSET'; )
2) Create a NEW database with the NEW database characterset you want to use.
3) Import the export file with the NLS_LANG set to the character set of the
source (OLD) database.
4) The character set conversion will be done at the moment that the import
executable inserts the data into the new database.
5) Backup the new database.
3. Using a combination of ALTER DATABASE CHARACTER SET and export/import
------------------------------------------------------------------------
In some cases you might find that csscan tells you that most of your data is
CHANGELESS but only one (or a small number) of your tables is CONVERTABLE.
In that case you would still have to use export/import. If the size of the
database is particularly large and using export/import will cause too much
down time you could follow this method:
a) Export the data from the tables that come out as CONVERTABLE.
b) Truncate or drop those tables.
c) Now you have a database with only CHANGELESS data. Because the character set
is not classed as a subset of the new character set you cannot use the normal
form of the ALTER DATABASE CHARACTER SET command. The command usually simply
checks if the new character set is a superset of the old character set, it does
not check the actual data. In order to force the change please contact Oracle
Support. Provide them with the output of csscan showing all data is classed as
CHANGELESS and they will then assist you in forcing the character set change.
d) Now that the character set has changed we can simply import the data
exported in step (a). The import will convert that data so that it gets stored
in the correct way for this character set.
After changing the database character set
=========================================
Remember that changing the database character set only changes the way
characters are stored on the database. This should NOT have any effect on the
clients and you should not have to change the NLS_LANG for example. The
NLS_LANG on the clients should simply reflect the setup of that machine.
For more general information on setting up NLS_LANG and how client-server
conversion works please see the following notes:
Note 179133.1 The correct NLS_LANG in a Windows Environment
Note 264157.1How to set correctly NLS_LANG on Unix Environments
Note 229786.1 NLS_LANG and webservers explained.
Further reading
===============
Note 237593.1 Problems connecting to AL32UTF8 databases from older versions (8i and lower)
For further NLS / Globalization information you may start here:
Note 267942.1 Globalization Technology (NLS) Knowledge Browser .
Note 60134.1 Globalization (NLS) - Frequently Asked Questions
.
-
ahmadbilal
- Posts: 615
- Joined: Mon Sep 18, 2006 1:32 am
- Location: United Arab Emirates
- Contact:
-
ahmadbilal
- Posts: 615
- Joined: Mon Sep 18, 2006 1:32 am
- Location: United Arab Emirates
- Contact:
Thanks Keep me in ur prayers
[quote]Dear Ahmad Bilal Sahib
I am very thankful to you for timely assistance and help. If I need any further assistance then I will contact you again.
May ALLAH Almighty keeps you in peace and showers HIS more and more blessings upon you.
Best Regards.
Mazhar Hussain
<i><div align="right">Originally posted by shimlian
[quote]Dear Ahmad Bilal Sahib
I am very thankful to you for timely assistance and help. If I need any further assistance then I will contact you again.
May ALLAH Almighty keeps you in peace and showers HIS more and more blessings upon you.
Best Regards.
Mazhar Hussain
<i><div align="right">Originally posted by shimlian
Who is online
Users browsing this forum: No registered users and 3 guests