I've an SSIS package which works perfectly on various server but doesn't on 2 newly added server.
It uses OLEDB (64bit, I've certified that) to get data from an ORACLE DB from a table with 3 VARCHAR2 columns and upsert the rows to a SQL 2012 table with 3 nvarchar columns, with the same size.
The package was working flawlessly in all the servers we deployed it. We recently added 2 new servers, with hopefully (I personally checked the possible major culprit: ODAC, dtexec version, tns names ) the same software with the same versions but the package is not working anymore. It gives us the famous error:
Description: Column "C_CODE" cannot convert between unicode and non-unicode s
tring data types.
End Error
Error: 2016-08-26 08:33:26.20
Code: 0xC02020F6
Source: Upsert Lines OLE DB Source [87]
Description: Column "S_DESC" cannot convert between unicode and non-unicode s
tring data types.
End Error
Warning: 2016-08-26 08:33:26.20
Code: 0x800470C8
Source: Upsert Lines OLE DB Source [87]
Description: The external columns for OLE DB Source are out of synchronizatio
n with the data source columns. The external column "C_CODE" needs to be updated
.
The external column "S_DESC" needs to be updated.
End Warning
The first warning I got was the "Cannot read the code page from Oracle server" so I tried to put the "use the default one every time" in combination with ANSI or UTF-8 code pages ( used this website to get the codepages: https://msdn.microsoft.com/en-us/library/windows/desktop/dd317756%28v=vs.85%29.aspx ).
The only way I made it work was to manually modify the OLE DB Source block into the package by changing the external columns to ansi strings, making it not compilable in the dev environment, then put a data transform that would change the exernal columns to utf-8 string again.
This way it doesn't work in the other servers but does flawlessly in the "faulty" servers.
I was thinking that the fact the package cannot read the code page from Oracle server is the culprit but I couldn't figure out how to fix it.
The problem is not like the million of questions about this issue you can find anywhere. The error being given is from the OLE DB Source block. I know about the data conversion.
Thanks in advance
The issue was the NLS_LANG registry key's value, it was set to an incorrect value.
I solved by deleting the said key, all worked fine.
Just come across this post (and many others about this issue) and believe I have found the underlying cause. On my servers at least, the 64bit version of the Windows Oracle drivers has a bug in the install process. I have checked the 32bit version and this bug is not there which explains the behaviour.
It appears that the 64bit version creates the NLS_LANG registry key in the wrong location. By default the 64bit driver create it here - "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE"
I manually created it here - "HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient12Home1" which cured my issue. For reference my NLS_LANG key is set to "ENGLISH_UNITED KINGDOM.WE8MSWIN1252". I just created it as a copy of the string in the branch above.
I hope this helps others.
We use 32 bit SSIS with Oracle instant client, I need to add entry in this registration location
"Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ORACLE\KEY_OraClient12Home1_32bit"
The “NLS_LANG” value is “AMERICAN_AMERICA.WE8MSWIN1252”. This solved my problem.
Related
I'm trying to use SSIS to load some data from Oracle database to MSSQL database.
I created the project and used the ADO.Net source and was able to create a connection to Oracle and run queries and view results.
However when I actually run the package I get the following error:
Error: 0xC0208449 at Data Flow Task, ADO NET Source 2: ADO NET Source has failed to acquire the connection {EECB236A-59EA-475E-AE82-52871D15952D} with the following error message: "Could not create a managed connection manager.".
It seems similar to the issue here
And I did find that I have two oracle clients version installed "11.1" and "12.2".
One is used by PL/SQL and the other by other entity framework project.
If this is the issue I just wanted a way to tell the SSIS to pick-up the correct one.
I tried adding Entry in machine.config for "oracle.manageddataaccess.client" section with the desired version.
I also tried using other types of data sources but couldn't even create a successful connection
I tried changing the Run64bitRuntime property in the project to False
Note: I don't have SSIS installed on my machine.
Eventually, I just had to remove the entries related to 11.1 in path variable then restarted my machine.
Also I switched to "dotConnectForOracle" for connection and now it seems to be working fine.
I'm expecting issues related to other applications that might still be using the 11.1 version, but that will be a problem for another day.
Always make sure to write the user (oracle schema) in uppercase and some special characters [in my case it was $] in the password needs escape character even if you're using the wizard not the cmd
I still don't understand the whole issue but I hope this helps someone some day.
I have a number of packages in SSIS that moves data from an oracle data source to Sql Server.
A new package was failing and I could not figure out what was going on. It was giving the message "cannot convert between unicode and non-unicode string data types"
It was weird that the package worked on my local machine but when deployed to server it always failed.
I already do a data conversion of my string values from dt_Wstr to dt_str.
All of my string columns on SQL Server are varchar
At wits end I decided to try to change the nps_lang registry value for oracle on the server box.
These are the settings that I changed.
(old)AMERICAN_AMERICA.WE8MSWIN1252
(new)AMERICAN_AMERICA.WE8ISO8859P1
It worked! At least so I thought.
The next day all the other packages that had been running fine are now failing.
Now my questions are what are the difference between these two that would cause one to fail and the others not?
Is there a character set that I could use that would work with both?
Any other suggestions to get all of my packages to run successfully on the server?
I am struggling with the above - I've installed PowerQuery (64 bit Excel 2013 setup) and under the database connection options, despite following the instructions here to download the Ngpsql data provider for PostgreSQL:
https://support.office.com/en-ie/article/Connect-to-a-PostgreSQL-database-Power-Query-bf941e52-066f-4911-a41f-2493c39e69e4?ui=en-US&rs=en-IE&ad=IE
I can still only see a limited set of options under under the database list, which do not include a PostgreSQL database. Now having hunted around on the web I found this thread:
https://superuser.com/questions/950100/connect-to-postgresql-database-from-excel-2013-power-query-with-npgsql
Which seems to suggest that the reason I cannot see the Postgresql option is that I am not using an OfficePro installation (think it was home edition).
Does anyone have any pointers - any workaround for this? Or do I really have to get a different version of office to get data from a Postgresql db, short of converting the database into Access or something? Thanks
[I have Office 2013 Pro.]
I had to do this in addition to installing "PowerQuery_2.44.4675.281 (64-bit) [en-us].msi" (I ticked GAC installation on the installation dialog) and "Npgsql-3.2.3.msi". Also, rebooted the machine.
Everything then started to work connection-wise.
But when returning large amounts of data into Excel with Powerquery at times I would get "type cast" errors - I could not map it down to NULLs or anything easy to determine. Powerquery seems a fine tool for some usages and I am sure this error can be fixed with data transformation steps.
If you just want to get the postgres data - you can use VBA + ADO. I have just finished setting it up and it works.
Install "psqlodbc_x64.msi".
Add references to your vba project.
Finally I created the connection with this connecton string (no windows DSN setup required - modify the string below as per your setup):
cnn.Open "Driver={PostgreSQL Unicode(x64)};Server=127.0.0.1;Port=xxxx;UID=postgres;PWD=postgres; Database=db_name;"
I could also successfully add it as a data source using the same connection string.
I was trying to pull data from Oracle to MSSqlserver database using Linked server.
select * from [LINK_NAME]..SCHEMA.TABLE;
But it was failing with the below error:
The OLE DB provider "OraOLEDB.Oracle" for linked server "LINK_NAME"
supplied inconsistent metadata for a column. The column "COLUMN_NAME"
(compile-time ordinal 6) of object ""SCHEMA"."TABLE"" was reported to
have a "LENGTH" of 100 at compile time and 200 at run time.
I also need to pass argument at run time in where condition. I found OPENQUERY as a solution but it does not support arguments at runtime.
Try using the OPENQUERY Syntax to see whether that helps..
SELECT * FROM OPENQUERY(LINK_NAME, 'SELECT * FROM db.Schema.Table')
More about OPENQUERY ...
I found solution:
The error was coming due to database column type mismatch.
ORACLE was using NVARCHAR for datatype but in case of SQLSERVER it was VARCHAR.
As NVARCHAR is double the size of VARCHAR that is why it was showing size mismatch error.
Changing the data type to same worked for me.
I have found a solution posted by this blogger. Try it out!
This tool from Sysinternals/Mark Russinovich is the best, and my only regret that day was not launching it earlier instead of scouring Google and going insane. I’ve limited Procmon to just sqlservr.exe, as it’s the SQL Service itself that loads/handles the providers and not the ssms.exe. Also of note is that the sqlservr.exe is a 64bit process while the management studio is still just 32bit. As the server service is loading the provider, and the service process is 64bit, the provider must also be available in 64 bit format.
The ODAC112021Xcopy_x64.zip was installed to C:\Oracle. What Procmon showed me however is that sqlservr is attempting to find the oci.dll in any folder but his! (It iterates through the %Path% sysvariable). When it finally gives up on find the dll, the SQL Service is in a unstable shape and the only way to stop the service was to kill it via taskmgr/procexp. Clearly I can see that the “xcopy” deployment – while not giving me any error messages – it also did not set the PATH variable! And this is what this post is really about… adding C:\Oracle and C:\Oracle\Bin to the Path variable or maybe it’s about employing investigative tools earlier in the process instead of relying on your search engine skills.
sqlservr.exe can now find the relevant DLL’s. The OCI.DLL in the root and the OraOLEDB11.DLL in the Bin subfolder. At this point I could query the database! If you did my steps as above and you still get the same error, I strongly suggest using Procmon.exe as I have instead of jumping to the next search result.
Full post is here with more details.
Before you close me for a duplicate. I know there is a work around for this at the link below.
My question is: why is this "suddenly" happening? I work at company and we have probably 40+ dts packages running regularly. None have ever had this issue when going between our Oracle and SQL Server 2008 platforms.
I suspect it is because of some update to one of the platforms, or because we migrated to a new server for SQL Server.
Does anyone know what setting this would be that needs to be changed in order to avoid this?
Additionally, every package we create / edit throws warnings for this, however, every legacy package works just fine.
SSIS Package: convert between unicode and non-unicode string data types
You mention that you migrated to new SQL Server. I suspect that you also change architecture from 32-bit to 64-bit which can cause your problems.
To determine this is your case run your DTS/SSIS from command line using default dtexec from Program Files\...\Binn and second from Program Files(x86)\...\Binn.
Second you mentioned that your legacy dts works fine, try to delete their source adapter and recreate it and check if it'll cause your problem.
Possible solution: install 32-bit Oracle drivers and use them
from SQL Server Agent Job in tab Execution Options set Use 32 bit Runtime
Read carefully 64 bit Considerations for Integration Services
To fix this issue I used the connection type:
Microsoft OLE DB Provider for Oracle.
Note I did not have to install any special version
This alone did not fix the issue, I also had to edit my OLE DB Souce connection properties. Under Custom Properties is the choice for AlwaysUseDefaultCodePage. This is by default set to false, when I set it to true this fixed my issue. I have not seen this error come back since.