I have a strange problem where in the DEV environment everything is fine but in PROD SSIS reports an error about conversion from unicode to non-unicode. This error happens at the OLE DB Source task level. So, I don't even get the chance to use Derived Columns to perform the conversion.
We installed BIDS on the production server and the task is flagged as in error. When I try to open the properties, it tells me that the metadata is different from what is in the DTSX file. When I accept the offer to automatically correct, all faulty columns input type (External and output columns) have their type switch from DT_WSTR to DT_STR.
The descriptions of the tables involved are identical in DEV and PROD (same types for the columns). If I query for the character sets they are identical in both environment.
For your information, here is the query:
SELECT *
FROM v$nls_parameters
where parameter
like '%CHARACTERSET'
which returns:
NLS_CHARACTERSET WE8MSWIN1252
NLS_NCHAR_CHARACTERSET AL16UTF16
on both environment.
Any idea to solve this ?
Thank you,
Michel
You are likely running into a difference in the drivers installed/configured on the different machines.
I ran into a similar issue with MySQL Drivers a long while back. Version X.Y.Z.13 was developed against. Server got driver version X.Y.Z.14 and boom, invalid metadata.
You will want to examine the Dev and prod server version of metadata and determine which one is right for you. In my case, the Dev driver produced varchar (non-unicode) strings and that aligned with the target system whereas the newer driver they had installed in prod deduced they should have been nvarchar (unicode) strings. Reworking the nvarchar to varchar or changing the tables was outside of the allowable timeframe for the project and the insane rules the data management team used for table creation.
Related
I'm trying to extract data out of an Oracle database that is configured with the following:
NLS_CHARACTERSET EE8ISO8859P2
NLS_NCHAR_CHARACTERSET AL16UTF16
I'm working with SSIS 2008 R2 Standard (had to install Oracle 11g Client). Some accent are properly interpreted (e.g: é) but some are received as weird character and I can't find any way to convert them properly :( The Oracle database is used by our ERP that serves many countries around the world which probably explains the character set choice (I'm not debating if it's a good one or not, I'm a SQL Server guy, not Oracle).
I've tried different approach to extract the data from Oracle, none of which succeeded. I thought I could simply use something as:
SELECT CONVERT(FIELDNAME,'UTF8','EE8ISO8859P2') FROM xxx
Without success.. In my ERP I can see the following value:
"modèle" which is read "modcle" with the previous query through SSIS.
I kinda feel that there's no way I'm gonna get the proper data unless there's some magic formula that can be used. Any help would be appreciated.
Thank you.
All you need to do is set your NLS parameters using some ALTER SESSION commands.
Guess the parameter you need to change would be NLS_LANG
See this page for more information:
http://docs.oracle.com/cd/A87860_01/doc/server.817/a76966/ch2.htm
Strangely, I helped one of my teammates today to sort in Swedish using this. Hope it helps you too.
Is there a way to insert spanish words into the Oracle table - like 'España'.
When I try to insert it, it either takes the ASCII counterpart of it or replaces the 'ñ' with a '?'.
Has anyone done this before or knows a work around for it?
I found something while googling they told we have to mention spanish character set in init.ora file. I don't know how to do this and also setting nls_settings for client. I am using toad to connect to server which is located in UK.
Please help me in solving this problem.
First, you should check if the database was created with a character set that includes the Spanish characters that you want inserted. For versions of Oracle starting with 9i the wizards by default create the database using Unicode, so it shouldn't be a problem. But if the database wasn't created by you, this should be the first thing to check with the DBA that created it.
Which version of the Oracle server are you connecting to?
Which version of the Oracle client are you using? Which kind of Oracle client (OCI, JDBC, .NET)?
If the database was properly created it can be a problem related to the client platform.
And this is not simple to diagnose without information about the client OS, database client libraries that you are using and their configurations related to Natural Language Support.
So, I will point you to an Oracle FAQ related to this issue. It is a lot of material to read but it worths your time.
http://www.oracle.com/technetwork/database/globalization/nls-lang-099431.html
After searching here and on the web, I finally decided to post the question. I am running an SQL 2000 server, and linked an Oracle 9i server. Everything works fine when I run queries, and even updates and inserts from and to the Oracle Linked server (using both Microsoft OLE DB driver and Oracle OLE DB driver) using the OPENQUERY approach.
The problem is that, in order to clean code a bit, I want to use four part names in my queries. I am doing this also when querying other SQL linked servers.
But when I run the queries against Oracle using four part names I get this error: ( I am translating the error message from spanish. Probably the original message in english id different)
ERROR: OLE DB 'MSDAORA' returned an invalid column definition.
Error Code: 7318
Digging a bit, I learned that this is probably related to nos having the right collation name set in the linked server properties.
Now... I am not an Oracle expert, so I need to find out what collation is the schema I connect to using in Oracle (apps... yes, I know, I know... )
So, the plain question is... How do I find out what collation Oracle is using? I have access to the Oracle server via Toad... is there any query I can run in order to find this out?
Thanks!
I think you're looking for the NLS settings, which you can find from these views:
V$NLS_PARAMETERS — "Current values"
NLS_DATABASE_PARAMETERS — What the database was created with.
NLS_INSTANCE_PARAMETERS — From changes by ALTER SYSTEM
NLS_SESSION_PARAMETERS — Combined, plus ALTER SESSION
V$PARAMETER — System parameters, where a lot of this is changed (contains all kinds of stuff)
The documentation is rather lacking here (or, quite likely, I couldn't find the right document), but this should get you what you want.
You will probably have to log in as SYSDBA to read some of these views.
I am trying to migrate my Oracle db to SqlServer 2008 using SSMA. I defined some type mappings for columns. When I synchronize after converting schema it gives errors like: "Cannot find datatype datetime" or bit. These datatypes are valid SQL Server datatypes.
Why I am getting these errors?
Just a guess, but it's quite hard to provide more than that before you give more details... (the code being synchronized to SQL Server, first of all).
Do you have case-sensitive collation on your SQL Server? I believe SSMA may have problems in this case. Try synchronizing to case-insensitive DB.
Also you may try running generated SQL Server (translated) code in the Management Studio and then find the problem with generated SQL or DB setup from that point. Again, it's most likely possible to figure out the problem solely by looking at your generated SQL if it's indeed corrupted due to some bug in SSMA.
I'm working on a legacy application using VB6 and Classic ASP. We're using disconnected ADO recordsets to pass data back and forth. Normally this works. But what has started happening recently is for any inner/outer join, ADO is including these in the available records to choose from. So when were specifying a column to update (in the cases it errors out, the primary key column), it in turns updates the wrong column (with the same name). I know it's normal for ADO to pull the primary keys for any joined tables, but the default for this is for ADO to hide them. In our case ADO isn't hiding them.
What I've narrowed it down to is the SQL Native Client driver is not working correctly. I can go back to the SQL Server driver (SQL 2000) and it works great, but as soon as I switch back to SQL Native Client, it exhibits the behavior above. I've checked the properties on the open connection and the properties of the recordsets themselves, they match in every instance except one (the count of how many hidden columns there are which makes sense, as SQL Native isn't hiding them).
I've tried everything from deleting the MSADC folder from IIS and re-adding it, I've uninstalled SQL Native and reinstalled it (and subsequently upgraded it to the newest version). I've recreated the ODBC connection several times as well in the process of troubleshooting it. At this point I'm at a loss.
Also one thing to add, it appears SQL Native Client works fine on our other servers and no one else is having this issue. Anyone might have an idea of what could be happening? Thanks!
Edit : Example of what's happening (this occurs on for any query (stored procedures if it matters) and with >= 1 joins of any kind)
select temp_id, temp_value on temp_test
inner join another_table on another_table.temp_id = temp_test.temp_id
inner join yet_another_table on yet_another_table.another_id = another_table.another_id
this'll produce in the ado recordset :
SQL Native Client
(0) temp_id
(1) temp_value
(2) temp_id (primary key of another_table)
(3) another_id (primary key of yet another_table)
SQL Server driver
(0) temp_id
(1) temp_value
SQL Server 2005 will show it as it should be as : temp_id, temp_value
this occurs on for any query (stored procedures if it matters)
It's not the issue described here is it? :
If a change in the connection string changes the behavior, I would suppose that you have two different schemas, and then two versions of the same stored procedure; and the one that is executed with SQL Nativ Client is the incorrect one.
I have exactly the same scenario, and have had it for over a year on our servers and servers at our client. I never found a solution and as a result we simply have to use the SQL Server driver, which is a shame as SQL Native seems to connect significantly faster.
It's nothing to do with different schemas or different versions of the same stored proceedure as suggested above. I use a file dsn and simply changing the driver name changes the behaviour to/from that mentioned above. It seems to happen to all views (probably stored proceedures too as indicated)
If anyone does find a solution I'd be keen to hear about it.
Warwick