Our application has database Oracle 12c and Client in Java.
I wonder when using plsql developer for oracle then symbols i.e.° (degree) are displayed using system's language setting or plsql developer setting or oracle server character setting?
We have some symbols like degree which are displayed correct in some machine and some machine shows garbage character. How to do this setting to display symbols same in all systems?
I tried to store chr(176) instead of degree symbol (°) in database still no luck. It shows correct in my systems but shows null in my colleague's machine.
Related
A coworker made an SSIS package that pulls data from Oracle and transfers it to a SQL Server database that is nearly identical, so it's a lot of data flow tasks simply with an OLE DB Source (Oracle) to an OLE DB Destination (SS). When I open it on my computer, I get the error "Column [column name] cannot convert between unicode and non-unicode string data types" on all the source tasks. If I add a data conversion task to convert the unicode columns to non-unicode, all works fine but I really want this to work like how he has it because it's running on the production server like this. My best guess is it has to do with the installing of the Oracle client or drivers or the NLS_LANG variable but I can't seem to solve it. My environment variable NLS_LANG = AMERICAN_AMERICA.WE8ISO8859P1
I was worried something went wrong with my Oracle client installation because of my registry values. Now I have 3 clients installed since I went through the install process again. These are the third client's reg values and I added NLS_LANG myself and rebooted. I'm more of a SQL Server developer, so I'm possibly saying something wrong here.
The solution was to set the NLS_LANG environment variable value to AMERICAN_AMERICA.WE8MSWIN1252 to match what my coworker had and what my registry has because I somehow didn't notice they were different! However, neither NLS_LANG were set to start with so the real solution was to add this in. I rebooted and when I reopened the package, got zero errors.
enter image description hereWe are migrating Oracle DB from 12c Windows Oracle to 18c Linux Oracle installation. Some of the columns (derived columns) in views has become unicode and not usable by downstream SSIS. Any reason why these views are giving error in SSIS? SSIS is complaining that in 18c columns have become unicode
12c View definition is
enter image description here
18 c View defintion
enter image description here
I think your problem matches this :
Oraoledb: Cannot Convert Between Unicode And Non-Unicode String Data Types (Doc ID 960508.1)
This is due to a difference in metadata reported by the OleDb provider depending upon whether NLS_LANG environment variable is set. Typically this behaviour would be observed when the SSIS package is developed in an environment that has NLS_LANG set, and then deployed to an environment that does not have it set. The difference in metadata results in the error, and is being investigated via Oracle bug number bug 7836009.
To resolve this issue, set NLS_LANG to the same setting as the box the package was developed on, which result in the same metadata being reported in both cases.The NLS_LANG environment variable should be set in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_<homename>\NLS_LANG
Export the NLS_LANG variable in Linux with the same value as the original database
The behavior can also be worked around by refreshing the SSIS package after deployment, which will refresh the metadata.
Hope it helps.
Regards.
My package runs fine from both my desktop and my ETL server when I RDP into it. However, when running as part a job, I get the following error on all my string columns: "Error: Column "***STATUS" cannot convert between unicode and non-Unicode string data types."
The error occurs on an OLE DB Command component that updates a table in an Oracle database. None of my columns on either the SQL/SSIS side nor the Oracle side are Unicode. Here's the metadata directly leading into my OLD DB Command component.
I verified that the External Columns on the OLE DB Command component in question exactly match that metadata. I've also tried explicitly converting the columns to Unicode before inserting in case they were Unicode (I know they're not) on the Oracle side, but that leads to a hard error (red X) and the same message.
Here's the Oracle schema:
Command:
Anyone have any idea on how to get this to run from the agent?
Based on the following oracle support case:
Oraoledb: Cannot Convert Between Unicode And Non-Unicode String Data Types
The following error message cause is:
Developing an SSIS package that uses the Oracle OLEDB Provider on a 32 bit operating system and then deploying to a 64 bit SQL Server installation
Possible Workarounds
Note that i didn't tested these workarounds before.
(1) Try running the package in 32-bit mode:
From Visual Studio
GoTo Project properties >> Debugging >> Run64BitRuntime = False
From SQL Agent
Check the following link:
SSIS Package Not Running as 32bit in SQL Server 2012
(2) Install Oracle x64 oledb provider
64-bit Oracle Data Access Components (ODAC) Downloads
On the OLE DB Source ensure you have delay validation set to true.
I set the default code page to false and had the code page as 1252.
I have tried this both with 32 bit and 64 bit.
Also need to make the flag validateexternalmetadata = false
We have an SSIS package downloading data from an Oracle database to an SQL Server datawarehouse. For this datawarehouse, several environments are set up; Development, Test and Production. Dev and test share a machine, Prod is stand-alone.
When the SSIS package is run on the PROD machine, it downloads the Varchar2 columns from our Oracle source database to MSSQL in DT_WSTR format and saves this to a NVarchar column. I.E. all steps involved support Unicode.
When this same package is run against the same source database on the DEV/Test box, it somehow sees the external columns as being Varchar, derives this to DT_STR in the data flow and refuses to store this in an NVarchar column.
All OS's are Win2K8r2, MSSQL 2008 64 bits. The package is run in 32bits mode, same behaviour is seen when run from BIDS or from SQL Agent.
Anyone care to guess why? I've already seen the suggestion to disable validating external metadata (https://stackoverflow.com/a/18383598/2903056), but that's not a practical suggestion for our situation.
An old question I know, but seems to still be relevant. And since I could not find a suitable answer in the last 3 months I have been searching, I figure now is as good a time as any to post my findings.
I have had the same curious behaviour and have finally been able to resolve it.
My layout looked like this:
Oracle 10g R2 database on Windows 2003 Server (lets call it ORA)
Dev machine with Windows 8, Visual Studio 2012 + SSDT, Sql Express 2012,
ODT 12.1.0.21 (lets call that DEV)
Sql Server 2012 on Windows 2012 Server, Oracle Client 11.2 (lets call that TEST)
Both DEV and TEST were connecting to ORA. DEV was reporting VARCHAR2 columns as DT_WSTR while TEST would insist that they are DT_STR.
I then installed ODT 12.1.0.21 on TEST and the problem was solved. Notably, I used the "machine wide" option during the install. I am not sure how much of an impact that had.
There seems to be a difference in the datatypes that are returned by the Oracle OleDb providers across the different versions of the client side components.
Check the value of the NLS_LANG in the registry.
reg query HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_<orahome> /f NLS_LANG
If it matches the server's character set, OraOLEDB will use regular (non-Unicode) datatype DBTYPE_STR, otherwise it uses Unicode-mode, datatype DBTYPE_WSTR.
If the NLS_LANG field is missing, it defaults to US7ASCII which almost certainly will not match your database and you will be using Unicode datatypes.
To get the server's characterset, do:
SELECT parameter, value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';
Check Metadata validation property value if it true make it false
I have installed Cognos BI 8.3 on my machine, which has a Windows 7 OS 64-bit. In IBM's supported environment list for Cognos 8.3, Windows 7 is not listed. On top of that, it says the product will only integrate with 32-bit 3rd party libraries. So, you can already see that I'm already starting on a bad foot. But anyways, this is the machine I have and that is the software I got, so I decided to see if they would work together..
I installed Oracle 10g Express database also in my machine and Apache 2.2 server. Up to there no problems.
Before moving further, I copied ojdbc14.jar to cognos/.../webapps/p2pd/WEB-INF/lib and added the Oracle database in Cognos Configuration. Tested, passed.
With the database started, the Apache server started, and Cognos started, I was successfully able to start Cognos Connection on the computer. So, it looks like the OS is not an issue.
(You can see everything I did by following the steps on this site, which since two days ago seems to be down but I'm thinking will eventually come back up)
Then I decided to try the samples, so I tried to create a data source connection from Cognos to the Oracle database. So, in the admin config console (i.e. Administer Cognos Contents > Configuration), I decided to create a new Oracle data source. I put the credentials, but BAM.. testing fails.
Fail Message:
QE-DEF-0285 The logon failed.
QE-DEF-0323 The DSN(ODBC)/ServiceName is invalid. Either the DSN is missing or the host is inaccessible.
RQP-DEF-0068 Unable to connect to at least one database during a multi-database attach to 1 database(s) in:
testDateSourceConnection
UDA-SQL-0031 Unable to access the "testDataSourceConnection" database.
UDA-SQL-0532 Data Source is not accessible: "XE".
ORA-12154: TNS:could not resolve the connect identifier specified
RSV-SRV-0042 Trace back:
...
From what I have researched, it could be a number of things, but nothing seems to work. Here is what I tried:
Adding ODBC driver. Added the Oracle XE driver, even making sure it was done in the 32-bit ODBC manager (i.e. Windows\SysWOW64\odbcad32.exe). That didn't work.
Added ORACLE_HOME, LD_LIBRARY_PATH, and TNS_ADMIN to my environment variables.
tnsping'ed the XE database and it the ping returned ok.
There are no tnsnames.ora duplicates in the computer.
I tried and I am able to connect to the database via sqlplus. Did I mention that Cognos Config database test also passed?
Installed Oracle XE client. But didn't do much with it because the Oracle server is installed in the computer and also has a client component.
Has anyone come across this problem? I haven't been able to diagnose the problem or make even the slight progress for days. If you would like me to provide more information on any of the solutions I tried, please do ask. If you have a potential solution or, even better, if you have been able to solve this problem before, please let me know how!
Thanks!
One thing to keep in mind : certain portions of Cognos BI are implemented via Java and other portions are implemented via native C++ processes (the BI Bus processes)
Cognos connects to the content store database from the Java process using JDBC.
The BI Bus processes will connect to Oracle using a native oracle client.
So based on your description, I'd say that the problem area is in the native oracle client configuration (or the Cognos service's perspective of it).
You mentioned adding the ORACLE_HOME, LD_LIBRARY_PATH, and TNS_ADMIN environment variables in windows, and the fact that Oracle Utilities like SQLPlus and TNSPing are working for you.
When you added the environment variables, did you add them to the SYSTEM area for environment variables or the User area...?
If you're running Cognos as a service, its going to be a child process of SERVICES.EXE, which is run as system (this process is also not restarted unless you reboot the machine).
I'd try this :
make sure the above environment variables are defined for the SYSTEM user (in the system area, not the user area)
once you've done this, reboot the machine
See if you can create the database connection now.
If that doesn't work, I'd suggest doing a "run as" of SQLPlus or TNSPING as the SYSTEM user (and see if that works).
In order to use oracle as data source, you must install 32 bit client.
64 bit client will not work.
So if you installed oracle express 64 bit, and you don't want to uninstall it,
you can just install additional 32 bit client, and make sure to set it as your default home.