|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Yesterday @ 11:27 AM
Points: 1,407,
Visits: 2,020
|
|
serinor.e090266 (3/27/2009) I dont know if there is a problem, but i have tested the sentence in a SQL Server 2005
More information: 1) Output for SELECT @@VERSION
Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
2) See the attached document.
This server is 2005 or not?
It's a SQL 2000 server you are connecting to, you're just using the 2005 client tool to do so. This is perfectly legal and shouldn't affect (or is it effect) your results...it will still behave like a SQL 2000 server.
Generally speaking, Enterprise manager or SSMS can connect to anything earlier than it from what I've seen.
Jason Shadonix MCTS, SQL 2005
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Monday, May 13, 2013 12:01 PM
Points: 2,677,
Visits: 2,273
|
|
serinor.e090266 (3/27/2009) I dont know if there is a problem, but i have tested the sentence in a SQL Server 2005
More information: 1) Output for SELECT @@VERSION
Microsoft SQL Server 2000 - 8.00.2039 (Intel X86) May 3 2005 23:18:38 Copyright (c) 1988-2003 Microsoft Corporation Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
2) See the attached document.
This server is 2005 or not?
Nope that's definitely SQL 2000, SP4!
Kev
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Wednesday, March 13, 2013 11:45 AM
Points: 3,
Visits: 18
|
|
Even with newer version of SQL being stricter on mixing "union" statements such as select 7 union select 'A', the original explation is not adequite to say the least. If that is all the problem, then there is no need to have the follow-up select statements.
The fact is, if you work around the new "union" feature/bug, by breaking the insertion to 2 parts - select 1 union 2... and select "A" union select "B", you have all items inserted into the table. Then, you still likely get an error running the follow-up select statements - I did.
Regardless the select SQL executed with error or without error, the explanation is based on how SQL interprates those select SQL statements - that clearly is not universally the same as we can be seen by different posts.
In my case, SQL is doing a "implicit conversion" on Col to compare with 1 and 6, therefor it fails for values such as "A".
If I change the filter condition from Between 1 and 6 -> Between '1' and '6', it runs with out errors.
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Monday, October 25, 2010 6:09 AM
Points: 1,621,
Visits: 409
|
|
My Asnwer is perfectly valid i.e will display 1..6.. if we execute this query in 2000.
We should have this question specific to the SQL Server version.
Thanks -- Vijaya Kadiyala www.dotnetvj.vom
Thanks -- Vijaya Kadiyala www.dotnetvj.com SQL Server Articles For Beginers
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Tuesday, May 07, 2013 7:07 AM
Points: 1,146,
Visits: 1,847
|
|
Vijaya Kadiyala (4/1/2009) My Asnwer is perfectly valid i.e will display 1..6.. if we execute this query in 2000.
We should have this question specific to the SQL Server version.
Thanks -- Vijaya Kadiyala www.dotnetvj.vom It was specific to a particular SQL Server version. You didn't read the question carefully.
(PHB) I think we should build an SQL database. (Dilbert) What color do you want that database? (PHB) I think mauve has the most RAM.
|
|
|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Yesterday @ 1:47 PM
Points: 31,406,
Visits: 13,722
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Sunday, June 12, 2011 5:00 PM
Points: 195,
Visits: 80
|
|
I tried in SQL 2005. It worked fine.
While inserting, it perform implicit conversion of numerals into varchar.
But if SELECTed, it does not convert it.
|
|
|
|
|
SSC-Addicted
      
Group: General Forum Members
Last Login: Monday, March 21, 2011 8:57 AM
Points: 418,
Visits: 61
|
|
Julie Breutzmann (3/26/2009) While the question and answer were not ideal, this question was valuable to me because I learned so much from the discussion that followed.
I totally agree with Julie on this. I'd rather learn a valuable lesson without getting points than learning nothing while getting thousands of points. 
Jochen
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Sunday, April 14, 2013 8:55 AM
Points: 1,383,
Visits: 1,212
|
|
Just in case anyone "in the know" is still on this thread, can anyone explain this phenomenon in SQL Server 2000?
I looked for an explanation among the many (fascinating) comments on this thread, but didn't see this specifically addressed anywhere - I might well have missed it though.
The "simple" case fails in the way that was originally expected by the author, and in line with documented conversion rules:
Select 1 union Select 2 union Select 3 union Select 4 union Select 5 union Select 6 union Select 7 UNION Select 'A' union Select 'B' union Select 'C' union Select 'D'
Server: Msg 245, Level 16, State 1, Line 1 Syntax error converting the varchar value 'A' to a column of data type int.
That is normal / expected SQL Server behaviour.
When you add an INSERT (to a table with appropriate type) in SQL 2000, the error goes away:
Create Table Test(col varchar(10)) GO Insert into Test Select 1 union Select 2 union Select 3 union Select 4 union Select 5 union Select 6 union Select 7 UNION Select 'A' union Select 'B' union Select 'C' union Select 'D'
(11 row(s) affected)
Does anyone know why/how this happens? Is it a bug, or expected behaviour?
Sorry if this was already addressed, I would appreciate any comments/reminders pointing in the right direction.
http://poorsql.com for T-SQL formatting: free as in speech, free as in beer, free to run in SSMS or on your version control server - free however you want it.
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855,
Visits: 9,374
|
|
I believe that this happens in SQL 2000 because the compile "reads-ahead" or anticipates the datatype expected by the table column and then back applies it to the source expressions. Implementing something like this is highly dependent on the internals of the compiler which was completely rewritten in 2005.
So my guess is that that obscure feature was dropped as part of the rewrite. (These features can have some problematic side-effects too, though I cannot remember them at the moment).
-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung Proactive Performance Solutions, Inc. "Performance is our middle name."
|
|
|
|