My question might have the same title as this question: Sql collation issues when deploying live. However that question is 8 years old and talks about issue on different sql server.
My infos as below:
SQL Server is Turkish_100_CI_AI Windows Collation Name (Transact-SQL)
DB is Turkish_CI_AS (SQL Server Collation Name):
and
dev env: windows 8
test env: windows 2012
From this question:
Select City COLLATE DATABASE_DEFAULT AS Place, State, Country FROM DEPT1
UNION ALL
Select '' AS Place, 'Arizona' As State, Country FROM DEPT2
works properly on sql server.
Problem occurs when deployed to test server with the same connection string (to the same db)
So I can guess the issue related windows os differences only.
Error message is:
Implicit conversion of varchar value to varchar cannot be performed because the collation of the value is unresolved due to a collation conflict between "Turkish_CI_AS" and "Turkish_100_CI_AI" in UNION ALL operator.
When I run my UNION sql query.
What can be cause and how can I handle given error, in context of changing windows os only?
EDIT: Closing question as the colleague informs that db are not the same, so question is no more valid
Please execute this query in both environments:
select COLUMNPROPERTYEX(object_id('dbo.DEPT1'), 'City', 'Collation') as column_collation,
DATABASEPROPERTYEX(db_name(), 'Collation') as db_collation, db_name() as db_name;
If you get the error for the exact query from your question the difference is between your column collation and database collation.
If you did not define explicitly the column collation it's inherited from database collation, and there is no need to COLLATE at all when you execute your query WHITHIN THAT DATABASE.
If instead your query is executed in the context of another database, or you use temporary tables (that are created with the collation of tempdb) then you need to use COLLATE.
So please check one more time your db collation, your column collation, and the database(maybe your query is executed in another database then you think)
Related
I regularly end up developing on projects where either the Central Test server, or Prod server is an older version of SQL Server than my local install.
e.g. Prod is SQL Server 2014. Local install in SQL Server 2019.
Mostly that's fine, it just means I have to remember to only use old syntaxes. (:cry:)
But occasionally I forget which syntaxes are old. Ooops.
Obviously our test environments catch this, but it would be great to be able to tell my Local Server ... "only accept SS2014 syntax", and have these mistakes caught before they're committed/pushed.
I thought this was what CompatibilityLevel was supposed to do. But either it doesn't, or I'm using it wrong. (See below)
How should I achieve this? (other than just installing a different SQL version!)
Attempt so far:
Run ALTER DATABASE MyLocalProjectDB SET COMPATIBILITY_LEVEL = 120; (120 represents SS2014)
Run SELECT name, compatibility_level FROM sys.databases WHERE name = db_name(); to confirm that the previous command "worked".
Run DROP TABLE IF EXISTS [ATableThatDoesExist], to see if the syntax is accepted. It was.
DROP IF EXISTS was new to SS2016:
MSDN: IF EXISTS ... Applies to: SQL Server ( SQL Server 2016 (13.x) through current version).
Additional Source
Why hasn't this worked?
To store UTF-8 in varchar field in SQL 2019 we are running existing DDL into new SQL2019 db with LATIN1_GENERAL_100_CI_AS_SC_UTF8 collation.
Whole 30K Line of DDL is executing only a single stuff operation giving error.
update ad
set ad.APPDEFAULTNAME = stuff(APPDEFAULTNAME,len(appdefaultname)-charindex('_', reverse(appdefaultname))+2, len(APPDEFAULTNAME),it.index_title)
from APP_DEFAULTS ad
join #index_title it
on substring(APPDEFAULTNAME,len(appdefaultname)-charindex('_', reverse(appdefaultname))+2,len(APPDEFAULTNAME)) = cast(it.[index] as varchar(30))
What could be the reason ??
Whenever you use a database collation that is different from the instance collation you should enable Contained Database Collations, if possible. This will give you the following behavior, and in particular temp tables will use the DATABASE_DEFAULT collation:
In Azure SQL Database this is always on, and in SQL Server you enable it by setting your database containment to "partial".
Any suggestions how to restructure this simple query?
Hitting a SQL Server Database using DAO via VB6 (updated old code to work with new database) and somehow this query in one of the apps is giving fits.
Select I.sType, Count(I.BarcodeID) AS CountOfID
FROM (SELECT DISTINCT sType, BarcodeID From [Ready]) as I
GROUP BY I.sType
ORDER BY sType
I've pasted the query into SQL Enterprise Manager and it runs just fine as expected. It worked fine hitting the original Access DB. But somehow the DAO via ODBC hitting the SQL Server is generating:
"The Microsoft Jet database engine cannot find the input table or query"
Things I've tried:
Removing the ()
Removing "as I" and "I." notation.
Brackets around [Ready] and without (thinking it might be reserved
keyword).
Confirmed that the connection is to the ODBC for Sql Server (this connection is used for other queries too.
Checked SQL profiling tool and the query is making it to the server (edited, I was checking the wrong tool on SQL Express)
EDIT: just to sate everyone's concern that I'm not really hitting SQL Server, I edited the SQL command to an even simpler
SELECT DISTINCT sType, BarcodeID From [Ready]
and it works correctly ON the same connection, so the connection is 100% confirmed to be SQL Server, the error message is in error (reported "Access").
So the problem is with no doubt the query FROM a query.
UPDATE:
Definitely confirmed my suspicions that the query, albeit a normal one, is not working with ADO-> ODBC-> Sql Server.
The first step SQL is doing is trying to validate the columns, etc.. of the "from" table (which in this case is not a table, but a query itself).
When I run a basic SELECT DISTINCT sType, BarcodeID From [Ready] SQL checks the columns, keys, indexes, etc of the table called "Ready" (exec sp_special_columns N'Ready',NULL,NULL,N'V',N'T',N'U'), then proceeds to return the results.
When I use a subquery, SQL is firing the same check on the table def, but for a table called SELECT DISTINCT sType, BarcodeID From [Ready] which of course does not exist and it returns an error (exec sp_special_columns N'SELECT DISTINCT sType, BarcodeID From [Ready]',NULL,NULL,N'V',N'T',N'U'). VB6/ADO is reporting correctly that SQL says the table is not found. So apparently this query from a query stumps the capabilities of ADO->ODBC...
since the issue is clearly the Select FROM (Select From) structure of querying a query being incompatible with ADO->ODBC->SQL Server, my solution was simply to make the subquery a view in SQL and alter the query to select from that.
From the Object Explorer of SQL Server Management Studio I renamed a table from nameA to nameB. When I query SELECT * from nameB I receive the error
object name 'nameA' not valid
This happens both from Management Studio and an external application. SELECT * from nameA gives the same error.
Restarting the service didn't help. Table name in sysobjects is correct. Is there maybe another place where SQL Server looks up table names? Thanks, it's getting me quite crazy :S
I'm using SQL Server 11.0.2100.60
Solved with a workaround:
I generated scripts for table schema and data, dropped the table and run scripts to recreate table schema and data. NOTE: I needed to manually modify the generated scripts because of mistakes in smalldatetime fields which made the generated INSERTs fail.
So it seems that dropping tables resets the "denormalized" SQL Server internal catalog which was left inconsistent somewhen. Thanks MS! ;)
I have created a linked-server definition according to the article at :
http://www.ideaexcursion.com/2009/01/05/connecting-to-oracle-from-sql-server/
My aim is to transfer rows to tables at Oracle 11gR2.
After creating linked server, whenever I try to select a table using a query like :
SELECT *
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I get the error below :
Msg 7356, Level 16, State 1, Line 1
The OLE DB provider "OraOLEDB.Oracle" for linked server "192.168.1.188"
supplied inconsistent metadata for a column. The column "EVENT_OBJECT"
(compile-time ordinal 2) of object ""ESIPARIS"."T_ERROR_LOG"" was reported
to have a "LENGTH" of 50 at compile time and 100 at run time.
One more thing is that it duplicates field names whenever a select statment is prepared by "Sql Server Management Studio", some fields are duplicated as below :
SELECT [EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_DATE]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[EVENT_OBJECT]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[MESSAGE]
,[EVENT_ID]
FROM [192.168.1.188]..[ESIPARIS].[T_ERROR_LOG]
I would be very happy to hear from you about any ideas, thank you for your concern,
Best Regards,
Kayhan YÜKSEL
There are a number of scenarios which might throw this error:
your distributed query in SQL Server references a view with an underlying table in Oracle with a primary key column created in a certain way, Find out more
there's a bug when the querying a view with numeric columns. Find out more
it may be a problem with driver incompatibility, such as using the MS OleDB driver instead of the one Oracle provides.
If it isn't the driver one possible workaround is to use OPENQUERY. Otherwise. this support note contains general information on troubleshooting linked server and Oracle.
(This problem is a fairly generic one, so it turned out that the actual resolution was none of the things I suggested. I'm incorporating #kayhanyüksel's solution in the body of this response for the sake of completeness.)
Solved it with changes at listener and tnsnames. We are now able to connect from SQL Server to Oracle 11gR2 (running on 64 bit Red Hat Enterprise Linux 5.4 ) and vice versa. Documents followed are
- Making a Connection from Oracle to SQL Server
- The Oracle Gateways documentation
I had the same problem: The column ...... was reported
to have a "LENGTH" of 50 at compile time and 100 at run time. and duplicate column names when selected.
while i was trying to run a query in MS SQL from an ORACLE 11g database
I used the follownig type of query and it worked !
DECLARE #TSQL varchar(8000)
SELECT #TSQL = 'SELECT * FROM OPENQUERY(MyLinkedServer,''SELECT * FROM TableName'')'
EXEC (#TSQL)
where MyLinkedServer is the name of the linked server and
TableName is the name of the table.
here you have the link to the article that helped me: http://support.microsoft.com/kb/314520
Old thread but it may be useful to someone.
When I recently encountered this error, using as provider the MS OleDB driver instead of the Oracle OleDB provider solved the problem.
I have the same issue with 11g client but it was disappeared with client version 12 which works for me is using OPENQUERY and to_char with the field that makes problem.
I confirm that SQL management studio (no matter what version) gives many duplicated field. The only installing of last driver version we can have consistent queries. I hope it can be useful for you!