Re: NLS question

  • From: De DBA <dedba@xxxxxxxxxx>
  • To: adar666@xxxxxxxxxxxx
  • Date: Wed, 16 Mar 2011 17:32:54 +1000

As I read the original post, the character is non-existent in the database character set, not in the client. The OP seems to know who entered the character, and what character was entered.


In the past (oracle 7, 8) I've encountered this with databases that were configured with US7ASCII and french-language windows clients. Today (O10g, OAS) I see the same happen when a client copies and pastes content from a windows based application into a text box that is subsequently entered into a database that does not understand Windows code pages. In these cases the original client character set is known, so the querying client may be set up in the same way. As far as I understand, the bytes that make up the character are not changed between the client and the server. So as long as they are read with the same code page, they will continue to mean the same. Perhaps I my understanding of the NLS is incomplete, though..

I do agree that when the character is illegal in the inserting client character set, it would be difficult to enter it. It would probably even be impossible to enter it, as the client cannot encode it.

Cheers,
Tony.

Yechiel Adar wrote:
I beg to differ.

If you try to insert a character that is illegal in the client charset, to a database that has a different charset, it will put ascii 61 or 191 in the database. So you can not know what the client tried to write, like the problem that started this thread. Since the client does the translation the database gets garbage and there is no way to retrieve the original data that was intended to store in the database.

The only way to get exactly what is in the database is to use a client with charset that is EXACTLY the same charset as the DATABASE. This way there is no conversion and you get the data from the database, even if it contain characters that are illegal in the charset you use.

Yechiel Adar
Israel

On 15/03/2011 02:28, De DBA wrote:
The solution is to set the NLS_LANG parameter in the environment of the querying client to whatever it defaulted to on the inserting client,
--
//www.freelists.org/webpage/oracle-l





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


Other related posts: