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.
Related
I know so little about Sybase that I don't even know whether database link is the correct term in Sybase. What I'm looking for is a way to communicate with Sybase over Oracle's heterogeneous services, commonly called a database link in Oracle (linked server if you speak SQL Server).
We are a primarily Oracle shop with a healthy dose of SQL Server, but zero Sybase experience. As you might guess, we have a piece of software that happens to run on Sybase, and we need to get information out of its database.
Professional services from the software vendor have not been helpful at all; frankly, we don't even know if they gave us the correct driver.
Our Oracle DBA is as sure as he can be (without knowing anything about Sybase) that he has everything set up correctly on the Oracle side.
When we try to run a query from Oracle to get data from Sybase, we get:
select * from call_request#sybase
*
ERROR at line 1:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[SAP][ASE ODBC Driver][Adaptive Server Enterprise]Incorrect syntax near the
keyword 'where'.
{ZZZZZ,NativeErr = 156}
ORA-02063: preceding 3 lines from SYBASE
Complaining about syntax near "where" doesn't make much sense, since there is no predicate at all. And it doesn't help to add a dummy
where 1=1
We're completely unsure where to turn. What can we even check next? Where is the documentation for setting this sort of thing up? Any ideas what is wrong?
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
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