I´m looking for any information what could cause a package (that is working on multiple 2008 r2 environments) stop working when upgraded to 2012.
All the SQL-tasks have started to malfunction and I do not know why.
Here is an example .
I get a collation error, even though I recreated the database to be in right collation and remade the query, so it does not join anymore.
How is it possible to get a collation error without join!
use master
DECLARE #db varchar(100)
DECLARE #tid varchar(3)
DECLARE #queryta varchar(max)
SET #db= ?
SET #tid = ?
SET #queryta='
SELECT smt.nro COLLATE database_default as yr,
smt.type COLLATE database_default AS tyyppi,
ISNULL(CAST(CONVERT(date,smt.dt1) AS VARCHAR),''1799-12-30'') COLLATE database_default AS dt,
ISNULL(CAST(CONVERT(date,smt.dt12 AS VARCHAR),''1799-12-30'') COLLATE database_default AS dt2
FROM [mydatabase].[dbo].[table] as smt
WHERE smt.T_Id='''+#tid+'''
'
exec(#queryta)
The error:
[Execute SQL Task] Error: Executing the query "use master DECLARE #db
varchar(100) DECLARE #..." failed with the following error: "Implicit
conversion of varchar value to varchar cannot be performed because the
collation of the value is unresolved due to a collation conflict
between "SQL_Latin1_General_CP1_CI_AS" and "Finnish_Swedish_CI_AS" in
add operator.". Possible failure reasons: Problems with the query,
"ResultSet" property not set correctly, parameters not set correctly,
or connection not established correctly.
I am using SQL Server Data Tools to debug.
This is dribing me crazy, any and all help apprecieated!!
EDITED TO ENFORCE COLLATION, NO CHANGE
#RemusRusanu Is right. The server collation is Finnish_Swedish_CI_AS and the database collations are Latin something. The error is a bug in SSIS behavior as the query is valid and runs in the management studio.
I can not use use master command and 3 part naming to access the right database, the one with different collation. No amount of casting or enforcing collation seems to fix it (the server should have been set up with Latin something collation as all the DB´s seem to use it).
The solution was simply to change use master -> use mydatabase
Thanks for #RemusRusanu
Related
I'm migrating a SQL Server 2008 database to SQL Server 2019, I have used Microsoft Data Migration Assistant, to look for search any breaking changes, issues or syntax errors.
I getting errors for some of my procedures:
Object [dbo].[PROCEDURE1] has syntax errors. Must declare the variable or parameter "#SINI". Error number 70590. For more details, please see: Line 9, Column 16.
This is my procedure:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[PROCEDURE1]
#Refer AS varchar,
#Ret Decimal OUTPUT
AS
DECLARE #SIni AS Decimal
SET #SIni= (SELECT Ini FROM Table1 WHERE Refer = #Refer)
SET #Ret = #SINI
Probably you have a server with case sensitive collation. As is explained in the documentation, the identifiers for variables, GOTO labels, temporary stored procedures, and temporary tables are in the default collation of the server instance.. You may check this with the following simple statement:
SELECT SERVERPROPERTY('collation');
But, to fix the error, use the correct case-sensitive variable name:
...
SET #Ret = #SIni
...
As an additional note, declare your data types with the appropriate length (as #Larnu commented). The length attribute is optional, and in case of parameter declaration the SQL Server assigns 1 as length, so the #Refer parameter has data type varchar(1).
The MS documentation about differences Between Compatibility Level 80 and Level 90 is telling on Compatibility Level 80, "Empty SET statement (with no SET option assignments) is allowed."
What is Empty SET statement (with no SET option assignments) ?
Please give me example to clarify this?
This seems to be very old behavior and the only thing I have found is from some German forum:
In SQL Server 2000, the list of deprecated features in SQL Server 2005
has compatibility level 80 with the entry "Empty SET statement (with
no SET option assignments) is allowed." and compatibility level 90
with "Empty SET clause." is not allowed. ".
But what is an Empty SET statement?
My first thought was a SET statement without any further assignment.
But actually this idea was too suspicious for me, because what brings
a SET statement without assignment?
Only after some research I found something. In fact, it is possible in
SQL Server 2000 to simply place a SET in an SP - without any
assignment.
There is also a somewhat strange syntax that is used - for whatever
reason:
DECLARE #CustomerId As nchar (5)
SET SELECT #CustomerId = 'ALFKI'
SELECT * FROM dbo.Customers WHERE CustomerId = #CustomerId
I do not even want to think about the sense and nonsense of the SET
SELECT statement. The fact is that SQL Server generates 2 statements
(SET and SELECT) out of it. And a SET statement without assignment is
no longer possible with SQL Server 2005.
As soon as nothing like this exists, you are save to change the compatibility level.
I'm writing a script in Sybase ASE where I call a stored procedure in SQL Server. The problem I have is that I'm getting an error from Sybase but not from SQL Server.
The Script in Sybase is as follows:
declare #input varchar(4000)
select #input = '111,222,333,444,555'
exec GATEWAY.MyDataBase..MyStoredProcedure #input
And this is the error:
[Error] Script lines: 1-5 --------------------------
Conversion failed when converting the varchar value '555.............................................................................................................................................' to data type int.
Msg: 245, Level: 16, State: 1
Server: GATEWAY, Line: 0
My stored procedure in SQLServer
I don't know why Sybase adds that right padding. The only way I can get it work is declaring the variable #input as varchar(255) or shorter.
What I tried without luck:
Adding a rtrim and ltrim in sybase
Setting the variable as TEXT
Adding rtrim and ltrim in SQLServer
adding a replace(#input,' ', '')
Wanted to replicate the problem in SQLServer adding the pad to the right but it still works.
The important thing is that: I can excecute it from SQLServer but it throws error from Sybase with the same input data.
Any help would be very appreciated. I guess it has something to do with the size of the varchar but no clue yet.
You can create a remote procedure in Sybase like this:
CREATE PROCEDURE "DBA"."uspSQL_CreateTicketsByCaseNo;1"( in #caseNo varchar(8) )
at 'SQL;dbName;dbo;uspSQL_CreateTicketsByCaseNo'
You can also right-click the Procedures & Functions and use the wizard to create a remote procedure. Then call the remote procedure like this:
CALL "DBA"."uspSQL_CreateTicketsByCaseNo;1"( caseNo )
It works for me.
I'm having a temp procedure:
CREATE PROCEDURE
#update_ListItemEntityNumberValueAndLocalizations(
#modelPrefix NVARCHAR(255),
#definitionNeutralName NVARCHAR(255),
#listItemNeutralValue NVARCHAR(255),
#newNumberValue float,
#listItemEnName NVARCHAR(255),
#listItemDeName NVARCHAR(255))
In this procedure there is the following if statement:
if(#listItemEnName is not null)
And at this line I get the following error:
Cannot resolve the collation conflict between
"SQL_Latin1_General_CP1_CI_AS" and "Latin1_General_CI_AS" in the is
not operation.
Does anyone know why this happens and how I can avoid it?
UPDATE: Database collation is SQL_Latin1_General_CP1_CI_AS
Why does a "is null" needs the collation?
Is there a way to cast the null or set the collation of the parameter?
Use an explicit collate clause
if(#listItemEnName COLLATE Latin1_General_CI_AS is not null)
Or alternatively dependant upon what the stored procedure does switching the context to USE tempdb; then creating the temporary stored procedure and then switching the context back to your original database might work as below.
You are creating a temporary stored procedure so the parameter will be regarded as having the collation of tempdb. However tempdb must have a different collation from your user database.
As far as I can tell from experimentation when the stored procedure is first created it is bound to the database context in use (even if it is later ALTER-ed from a different database context).
. e.g. I am on a case sensitive collation but if I create the following procedure in a case insensitive database
CREATE PROC #Foo2
AS
IF 'a' = 'A'
PRINT 'Yes'
SELECT *
FROM sys.database_files
No matter what database I run it from it or if I alter it when USE-ing a different database it continues to print "Yes" and return information about the original database's files.
I am having following issue.Even after case insensitive collation. SQL server is treating #Result and #result differently. Am i missing something.Please help.
SELECT DATABASEPROPERTYEX('OA_OPTGB_0423', 'Collation') SQLCollation;
SQL_Latin1_General_CP1_CI_AS
DECLARE #Result varchar(2000)
SELECT TOP 1 #result = addr.address_id
FROM dbo.address addr
JOIN dbo.company_address compadd ON addr.address_id = compadd.address_id
ORDER BY addr.address_id desc
...throws this error:
Msg 137, Level 15, State 1, Line 2
Must declare the scalar variable "#result".
Edit:-
This same query works in my local machine.I tried it and got no error.
From MSDN:
Identifier Collation
The collation of an identifier depends
on the level at which it is defined.
Identifiers of instance-level objects,
such as logins and database names, are
assigned the default collation of the
instance. Identifiers of objects
within a database, such as tables,
views, and column names, are assigned
the default collation of the database.
Variables, GOTO labels, temporary
stored procedures, and temporary
tables can be created when the
connection context is associated with
one database and then referenced when
the context has been switched to
another database. Therefore, the
identifiers for variables, GOTO
labels, and temporary tables are in
the default collation of the instance.
So even though you're attempting to declare the collation of the database, variables are always going to use the default collation of your SQL Server instance.
If you've just reinstalled your database into a new instance, you should consider either upgrading your code to comply with the new collation (probably what I would do), or else follow this document on how to change the instance collation.
Really though, it seems a bit sloppy to have randomly cased variable references ;)
Collation deals with data (values); not identifier names.
There is no reason for your sample to fail unless you're running the statements as separate batches as your declarations only have scope local to the batch.
If you're running the statements one-at-a-time .... there's your problem!
Otherwise check what you have configured as a batch separator; the default is GO