We have a web service (closed source) that accesses an Oracle 11g database. It was recently upgraded from 10g to 11g. It returns records, one of the columns being an NCLOB type. The string sent to the webservice may contain Windows NewLines, \r\n. Unfortunately, I'm not sure what, if anything the web service was doing to manipulate the data sent/received from the DB.
In 10g, the string returned from the NCLOB column was Big Endian Unicode, and all '\r' were dropped, so new lines would return as a \n.
In 11g, the string returned from the NCLOB is ASCII encoded, and all '\r' were replaced with '\n', so new lines return as \n\n.
Does this seem reasonable? Honestly, we've been handling Oracle newline issues for a while (the behavior of 10g), and I'm pretty sure that this is a result of upgrading to 11g. Does anyone have information on differences between 10g and 11g, related to newline or escape character sequence storage or the NCLOB datatype? I'm trying to do damage control here and point the finger at Oracle 11g, but need some evidence.
How this is interpreted on the client depends on the client nls settings. You need to check if your client nls settings changed. Especially check the setting of the NLS_LANG environment variable. This needs to be set on a user basis. In windows this might be set in the registry.
Related
I have an agent written in Lotuscript (IBM Domino 9.0.1 - Windows 10) that reads records into a DB2 database and writes them to Notes documents. The table in DB2 (Centos OS) contains international names in Varchar fields such as "Łódź".
The DB2 database was created as UTF-8 CodePage: 1208 and Domino by its nature supports UNICODE. Unfortunately, the value loaded in the notes document is not "Łódź" as it should be but it is "? Ód?".
How can I import special characters from DB2
in Domino NSF DBs in correct ways?
Thank you
To import the table I used the following code taken from OpenNtfs XSnippets:
https://openntf.org/XSnippets.nsf/snippet.xsp?id=db2-run-from-lotusscript-into-notes-form
Find where the codepage conversion is happening. Alter the lotusscript to dump the hex of the received data for the column-concerned to a file or in a dialog-box. If the hex codes differ from what is in the column, then it may be your Db2-client that is using the wrong codepage. Are you aware of the DB2CODEPAGE environment variable for Windows? That might help if it is the Db2-client that is doing the codepage conversion.
i.e setting environment variable DB2CODEPAGE=1208 may help, although careful testing is required to ensure it does not cause other symptoms that are mentioned online.
Using Rational Application Developer for Websphere 9.1.0 to make a data connection to a DB2 iseries file, the column data displays a Hex(I think).
I have added the "translateBinary=true" property to the url connection but is does not change the display results.
jdbc:as400:host;translateBinary=true
DB2 for iSeries uses EBCDIC natively but the Toolbox JDBC driver will automatically attempt to translate EBCDIC to unicode for you. Since only some fields are not being translated, it is likely those fields are tagged with CCSID 65535 indicating to the Toolbox driver not to translate them. You can either tag those fields with a CCSID indicating to translate, or use the translate binary driver property, which you're attempting to. The property is not working because you mis-typed it. According to this faq, it should be ";translate binary=true" instead of what you've tried.
I have recently started using PostgreSQL for creating/updating existing SQL databases. Being rather new in this I came across an issue of selecting correct encoding type while creating new database. UTF-8 (default) did not work for me as data to be included is of various languages (English, Chinese, Japanese, Russia etc) as well as includes symbolic characters.
Question: What is the right database encoding type to satisfy my needs.
Any help is highly appreciated.
There are four different encoding settings at play here:
The server side encoding for the database
The client_encoding that the PostgreSQL client announces to the PostgreSQL server. The PostgreSQL server assumes that text coming from the client is in client_encoding and converts it to the server encoding.
The operating system default encoding. This is the default client_encoding set by psql if you don't provide a different one. Other client drivers might have different defaults; eg PgJDBC always uses utf-8.
The encoding of any files or text being sent via the client driver. This is usually the OS default encoding, but it might be a different one - for example, your OS might be set to use utf-8 by default, but you might be trying to COPY some CSV content that was saved as latin-1.
You almost always want the server encoding set to utf-8. It's the rest that you need to change depending on what's appropriate for your situation. You would have to give more detail (exact error messages, file contents, etc) to be able to get help with the details.
I'm connecting to a remote Firebird 2.1 DB Server and i'm querying data that contains some cyrillic characters togeather with some latin ones.
The problem is that when i deploy the app on the production system, the cyrillic characters look like this: ÂÚÇÄÓØÍÀ. In addition, when trying to log what comes in from the DB, the cyrillic content is just skipped in the log file (i.e. i'm not seeing the ÂÚÇÄÓØÍÀ at all).
At this point i'm not sure whether i'm getting inconsistent data from the DB OR the production environment can't recognize those characters for some reason.
I've been wandering about for quite some time now and ran out of ideas, so any hints would be great.
The Dev machine that i use runs Windows 7 Ultimate SP1. My system locale is Bulgarian
The Production Server is accessed via Paralles Plesk Panel, and i'm not sure what's underneath.
If you did not specify any character set in your connection properties, then almost all Firebird drivers default to connection character set NONE. This means that Firebird will send the bytes of strings as they are stored in the database without any conversion, on the other side the driver will use the default system character set to convert those bytes to strings. If you use multiple systems with various default system character sets you will get different results.
You should always explicitly specify a connection characterset (WIN1251 in your case), unless you really know what you are doing.
My database(Oracle 10g) characterset is set to ISO-8859-6(AR8ISO8859P6) to store arabic characters.
When I query the database, JDBC Converts the data from the database character set to Unicode.
Because of this unicode conversion some of the characters are lost(translated to ?)
same behavior for both oci and thin..
In JAVA Is there any solution to retrieve the data in database format(without doing any unicode conversion)?
Is there any driver available retrieve the data from oracle in database format( encoding)?
Thanks
I doubt that any conversion TO Unicode can fail. But a conversion FROM Unicode to something else might fail. This can be the case when storing back the data or - most likely - on output to some terminal or UI.
If that's not the case: Can you give us some examples for each step?