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
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).
I am using R to run a stored SQL procedure:
query.str = "EXEC [StoredProcedure].[Procedure1]"
con <- odbcConnect("my_database")
my_data = sqlQuery(con, query.str)
This code works fine on my laptop. But when I try to run it on the server it gives an error:
42000 2812 [Microsoft][ODBC SQL Server Driver][SQL Server]Could not find stored procedure
I don't think this is a problem with the stored procedure itself, as I have encountered the same situation with multiple stored procedures (they work on my laptop but not the server).
Edit: I am sure the connection string works. When I use the same connection string for a non-stored-procedure, it works and data reads in just fine. The problem only occurs with stored procedures.
Thank you in advance!
Solution found: going through the Window Odbc connector, changing the default database to be the desired database fixed the problem.
This error may raise due to three main issues:
Incorrect reference of object's encapsulation including schema or database.
Every SQL Server object (table, stored procedure, function, etc.) resides in a schema and every schema resides in a database. Also, every object can be referenced by multi-part names. The default schema in SQL Server is dbo. Therefore by not specifying the database and schema in object reference, object is assumed to reside in connecting database and dbo schema. Consequently, below calls are equivalent:
EXEC [myServer].[myConnectedDatabase].[dbo].[myStoredProcedure]
EXEC [myConnectedDatabase].[dbo].[myStoredProcedure]
EXEC [dbo].[myStoredProcedure]
EXEC [myStoredProcedure]
If myStoredProcedure does not reside in either specified database or schema, this error would raise. If you do not know or remember where stored procedure resides, run queries on system sys views, INFORMATION_SCHEMA views, or system stored procedures, sp_*.
Incorrect spelling of stored procedure including not escaping special characters or reserved words.
To escape spaces, special characters (non-alphanumeric and non-underscore), and reserved words, enclose object names in square brackets [...]. Even better avoid such names. Thankfully for you, by default SQL Server is not case sensitive regarding identifiers. In other RDBMS's, like Oracle and Postgres, case sensitivity is retained for mixed cases during CREATE TABLE stage and double quotes would be needed for mixed cases types (i.e., "myStoredProc" <> mystoredproc <> MYSTOREDPROC).
Non-existent object in database or schema either by deletion or transfer to a different database or schema.
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
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When I execute this format of SQL command: SP_HELPTEXT Sproc1 .
The result set will display Could not find stored procedure 'SP_HELPTEXT'. But if i will replace the SQL command to lower case like sp_helptext Sproc1 , it definitely displays the content of Sproc1.
Im using the Sproc1 in my program and when the program executes Sproc1 it will return a message:
Must declare the variable '#Variable1'.
Although I've already declared that specific variable.
I have a hint that the issue is related to collation, case-sensitive or insensitive settings. Does anybody know how to resolve ?
Another situation where case sensitive variable names appear:
CREATE PROCEDURE Foo #customerID int AS
PRINT #customerId
You have a case sensitive server collation.
Your database has a (as you have shown) a case insensitive collation but when you have a case issue with variables it is the server collation that matters.
The same goes for sp_helptext which is a stored procedure defined in database master with lowercase. So when you call SP_HELPTEXT it is not found.
To fix your stored procedure to work in a case sensitive server collation you have to make sure that every reference to the variable #Variable1 is exactly that. Not #variable1 or #VARIABLE1.
Use this to check what server collation you have.
SELECT SERVERPROPERTY('collation');
From the SQL Server Books Online:
COLLATE (Transact-SQL)
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.
For example, two tables with names different only in case may be created in a database with case-sensitive collation, but may not be created in a database with case-insensitive collation. For more information, see Database Identifiers.
The identifiers for variables, GOTO labels, temporary stored procedures, and temporary tables are in the default collation of the server instance.
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.
See also
MSDN forums: Why are my SP's throwing a case error when pushing to a db using BIN collation?
Case sensitive variables in SQL Server
SQL Server stored procedure case sensitive?
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.