Posted inSQL
Microsoft
15 years ago
SQL Server should not raise illogical errors
You already have tons of these bug reports, and I bet that you have closed them all by design and told people to use the CASE statement. But, no, you are wrong. This is a bug, and should be fixed. Although the fix is to add new functionality, hang on.
Declined
ProgrammabilityBugsDeclined
Company Response
Microsoft
Company Response
Up: 82<=-=Mar 3 2010 10:44AM=-=>Hi Erland,Thanks for your feedback. We are aware of this request and hope to address it in a future version of SQL Server.�Umachandar, SQL Programmability Team<=-=Jul 21 2010 5:36PM=-=>This bug cost me and others about 8 hours of troubleshooting this week. And the query was working until statistics were updated. That�s the spooky part, that a new join order can cause an error in a previously-working query. This was compounded by the fact that the query was in a UDF and 1) error messages don�t list the line in the UDF but rather the calling SP and 2) I know of no way to see the execution plan of a UDF, which would have helped because I could have seen in the plan the conversion to float before the JOIN to the filtering table.<=-=Mar 9 2011 12:08PM=-=>Are you sure this is a bug emtucifor? SQL is a standard, and it has very specific rules about when expressions can be evaluated in a SQL expression. Do we know for a fact where it is specified that the optimizer is not allowed to evaluate expressions in the Select clause before those in the where clause?<=-=Mar 11 2011 4:11AM=-=>I agree that there is room for improvement here, though I don�t necessarily agree that less errors should be raised.I once had to analyze a report that turned out to rely on a custom to only use integers in a de facto varchar(9) key field. It worked when the query was designed and simply stopped working after someone mistyped, and immediately marked the wrongly keyed record for deletion. The author contends that a query that works once should not throw errors unless the schema actually changes. I�d say the query shouldn�t have worked in the first place.My suggestion: Throw warnings on any implicit char-int conversion (including some trace flag to turn them off). Throw warnings for char literals used as date literals unless they conform to iso8601 (was that the number?). Optionally define hints to allow specifying one way (�pester me until the query i..
Vote
0 Comments