views:

100

answers:

2

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.

+2  A: 

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 ;)

womp
If i follow this why is this query working on my machine. I restored an old backup of a database and tried running this query.On this server,SQL server was reinstalled and after that this problem in occuring.
Rohit
He isn't trying to set the collation. I presume line 2 is his result from executing line 1 (to prove he has case-insensitive collation). However, collation is irrelevant because it deals with data values, not identifier names. Transact-SQL is a case-insensitive language, so matter what collation is used, the identifier names are case-insensitive. However, I agree wholeheartedly with your statement: "it seems a bit sloppy to have randomly cased variable references".
Craig Young
@Craig - his SQL statemenst aren't trying to set the collation, but I was just inferring from his question that he was perplexed as to why setting the database's collation wasn't solving the variable naming issue.
womp
@womp: My point is that collation has zero bearing on his problem. The **language** is _case-insensitive_ - no matter what collation is used! @Result and @result are the same, and his problem is elsewhere. (Side Note: He responded to my answer that he was using a stored proc; if he presents the code of his stored proc and the problematic call, there may be a chance of discovering what is actually wrong.)
Craig Young
A: 

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
Craig Young
It is a simple StoredProcedure.
Rohit