This discussion is archived
3 Replies Latest reply: Oct 10, 2013 9:31 PM by andrewmy RSS

database character set for forms

lake Journeyer
Currently Being Moderated

I am sorry if this is a dumb question. I plan on upgrading from 10.1.5 database to 11gr2. We currently use forms 11.1.1.4 and 6i.  After upgrading

the database I hope to upgrade forms to the most recent version.  Is there a certain character set that I should use in the database to accommodate

forms 11.1.1.4 and 6i or can I just use whatever the default is?

  • 1. Re: database character set for forms
    andrewmy Journeyer
    Currently Being Moderated

    You should use whatever characterset is currently in your original 10g database to avoid issues with forms and reports.

  • 2. Re: database character set for forms
    lake Journeyer
    Currently Being Moderated

    That sounds prudent! I'll try that.

    I see that our 10.1.0.5 database apparently uses:

    NLS_CHARACTERSET               WE8MSWIN1252

     

    whereas a previously installed 11gr2 database defaulted to this:

    NLS_CHARACTERSET  AL32UTF8

     

    I had previously installed 11gr2 to run apex with a link to the 10.1.0.5 database. A peculiarity there was that all the

    character fields became 2x as large when viewed in 11 across a link to 10. That was apparently an effect the bitness

    difference. Distracting. It was the case however that entering data on the 11 side going to its real home in 10 did end up ok but it was worrying.

     

    I have a feeling though that using we8mswin1252 is going to preclude something else from working. What is it?

    I can live without apex. I might want to use jdev and/or locally developed servlets. Would there be a problem there?

    (yeah I suppose this is a database question..)

  • 3. Re: database character set for forms
    andrewmy Journeyer
    Currently Being Moderated

    Unicode is preferable because of better support for languages. If there is such a need (now or in the future) to store characters that your current characterset cannot accommodate that may be good reason to migrate to AL32UTF8.

     

    If I were creating a new database from scratch I would be choosing unicode charactersets such as AL32UTF8. But if you already have a database using a different characterset there will be a migration (export/import) involved instead of a possible straight upgrade in place to 11g. Also because AL32UTF8 stores characters as multibytes your existing forms / reports may need a review to see how much code change is involved. If you intend to change characterset you can try migrating a copy of your existing database to AL32UTF8 for testing.

     

    Useful links:

    Oracle Globalization Support Guide

    Migrating WE8MSWIN1252 to AL32UTF8

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points