Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: ASCII / EBCDIC issue

Re: ASCII / EBCDIC issue

From: Luc Gyselinck <Luc.Gyselinck_at_nospampandora.be>
Date: Mon, 07 Jun 2004 20:37:15 GMT
Message-ID: <%l4xc.147847$Nn7.7534710@phobos.telenet-ops.be>


"Why not re-create the database using AL32UTF8 as the character set?"

On the mainframe, z/OS native, choosing this database character set results in an ORA-12706 error...

ORA-12706 this CREATE DATABASE character set is not allowed

Cause: An attempt was made to create a database on an ASCII-based machine using an EBCDIC-based character set or vice versa. This is not permitted.

Action: Create the database using either ASCII-based or EBCDIC-based character sets, depending on what is supported by the hardware. Refer to your Oracle operating system-specific documentation for more information about the type of character set supported.

The NATIONAL character set can be set to AL32UTF8 (the default), but we had to set it to UTF8: after the upgrade from Oracle8i to Oracle9i, the Forms6i application generated a lot of ORA-00600 on the database and/or some data was incorrectly handled by Forms. An upgrade to Forms10g is planned for mid July (the application has been upgraded and tested and is now in the acceptance fase).

Luc

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:40c4cd88$0$3038$afc38c87_at_news.optusnet.com.au...
>
> "Luc Gyselinck" <Luc.Gyselinck_at_nospampandora.be> wrote in message
> news:p%3xc.147827$Ik7.7528517_at_phobos.telenet-ops.be...
> > Oracle 9.2.0.4 on IBM AIX / Forms 6i Web on WinNT
> >
> > One of our customers plans moving an existing database from the IBM AIX
> Unix
> > box to a z/OS IBM mainframe platform. Now, we are facing the following
> > issue:
> >
> > On the Unix box, the database was created with a characterset
> WE8ISO8859P1.
> > The application uses the NLS_SORT=BINARY environment variable/registry
> key.
> > The z/OS database is created with the WE8EBCDIC... database characterset
> > (WE8ISO8859P1 is not available on z/OS). After a successful
export/import,
> > all rows are ordered differently by the ORDER BYs, because the ASCII
> > character sequence is different than the EBCDIC character sequence
(ASCII:
> > 0..9..A..Z..a..z, EBCDIC: a..z..A..Z..0..9).
> >
> > The customer does (currently) NOT want this difference in behaviour.
> >
> > One solution is setting the NLS_SORT parameter to ASCII7, but this will
> > introduce an extra SORT step in the EXPLAIN PLANs of many query
> statements,
> > downgrading performance (and some queries even do not return results in
an
> > acceptable time interval). So this will involve code changes,
performance
> > tuning,...
> >
> > Another solution would be to ALTER all VARCHAR2 table columns to
NVARCHAR2
> > columns (while setting the database NATIONAL CHARCATERSET to UTF8). The
> > result is that all NVARCHAR2 data is stored in UTF8 into the database,
and
> > we can keep the NLS_SORT parameter to BINARY.
> >
> > A third solution is that the customer should accept the fact that an
ASCII
> > environment IS NOT the same as an EBCDIC environment.
> >
> > But I need to investigate/plan the second solution, but I feel
> unconfortable
> > with this NVARCHAR2 solution. Is this a good or bad idea ? Are there any
> > known issues, gotchas, ...?
> >
> > Thanks
> > Luc Gyselinck
>
> Why would you want to change all your data types for all text columns in
all
> tables, when the database character set is there for that sort of thing?
In
> other words, why not re-create the database using AL32UTF8 as the
character
> set? (Don't use UTF8 as such, not even for the national character set,
> because it's only there for backwards compatibility, conforms to an
earlier
> Unicode standard, and its use is deprecated).
>
> Regards
> HJR
>
>
Received on Mon Jun 07 2004 - 15:37:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US