Re: Question on storing non english character

Thank You Mark. I was mainly concerned about the performance side of it, if any exists and that is why Oracle has not kept it default as VARCHAR2(N CHAR). But as you mentioned no such issue is there. And with respect to pl sql code/application code, are you saying the places where it's defined as hard coded type/length value in the code may cause break but the %TYPE definition won't cause any issue?.Or you are pointing to some other issue here?

On Thu, Aug 26, 2021 at 12:00 AM Powell, Mark <mark.powell2_at_dxc.com> wrote:

> If you want to start creating application tables using CHARACTER instead
> of BYTE semantics, I do not see a real downside providing your developers
> are aware of how they need to code the application to handle the column
> values returned.
>
> Mark Powell
> Database Administration
> (313) 592-5148
>
>
> ------------------------------
> *From:* Pap <oracle.developer35_at_gmail.com>
> *Sent:* Wednesday, August 25, 2021 12:13 PM
> *To:* Powell, Mark <mark.powell2_at_dxc.com>
> *Cc:* Oracle L <oracle-l_at_freelists.org>
> *Subject:* Re: Question on storing non english character
>
> Thank you Mark.
>
> Is there any downside(may be storage or performance/stats side etc) if by
> default we create all the new VARCHAR2 columns of table a VARCHAR2(N CHAR)
> even if the column is going to just hold all english/single byte
> characters? Asking because, Oracle has not made that N CHAR as default ,
> which would have helped in accepting multilingual characters
> without modifying column types. So is there any reason for not doing that
> and thus a negative impact if we do so?
>
> On Wed, Aug 25, 2021 at 8:17 PM Powell, Mark <mark.powell2_at_dxc.com> wrote:
>
> Last I knew, "*Oracle recommends* that you leave this initialization
> parameter undefined or you set it to BYTE." This recommendation can be
> found in Database Globalization Support Guide. Check your version.
>
> Changing the parameter at the database level can impact existing
> applications. When creating objects, you can either change the parameter
> at the session level or code the table column definitions to explicitly
> specify character instead of BYTE.
>
> Mark Powell
> Database Administration
> (313) 592-5148
>
>
> ------------------------------
> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
> behalf of Pap <oracle.developer35_at_gmail.com>
> *Sent:* Wednesday, August 25, 2021 10:10 AM
> *To:* Oracle L <oracle-l_at_freelists.org>
> *Subject:* Question on storing non english character
>
> Hello Listers, We are getting some requirements in which many of the
> attributes in our database may need to cater to non english/multi byte
> characters. Currently we have the defaults setup as bytes at the database
> level. Which means if we create any attribute with varchar2(N) it defaults
> to varchar2(N bytes). And existing attributes are defined the same way ,
> say e.g varchar2(N bytes). so they have to be varchar2(N char) to work
> without fail.
>
> My question is , if there exists any downside if we set it(CHAR) as
> default at the database level? or say by default create all the new table
> columns as VARCHAR2(N CHAR)?
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l