InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSat, 25 May 2013 14:52:43 GMT20http://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Sean Lange (10/4/2012)[/b][hr][quote][b]Jeff Moden (10/4/2012)[/b][hr][quote][b]Sean Lange (10/2/2012)[/b][hr]It will work but referring to columns by ordinal position is fraught with maintenance issues. [/quote]Not to mention that (IIRC) it's been deprecated.[/quote]And something I have avoided like the plague long before it was deprecated.[/quote]+1Fri, 05 Oct 2012 12:12:11 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Jeff Moden (10/4/2012)[/b][hr][quote][b]Sean Lange (10/2/2012)[/b][hr]It will work but referring to columns by ordinal position is fraught with maintenance issues. [/quote]Not to mention that (IIRC) it's been deprecated.[/quote]And something I have avoided like the plague long before it was deprecated.Thu, 04 Oct 2012 13:03:21 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Sean Lange (10/2/2012)[/b][hr]It will work but referring to columns by ordinal position is fraught with maintenance issues. [/quote]Not to mention that (IIRC) it's been deprecated.Thu, 04 Oct 2012 12:36:04 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxThanks,PedroThu, 04 Oct 2012 10:16:41 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]PiMané (10/4/2012)[/b][hr]Regarding Dynamic SQL....Instead of a SELECT suppose I have an UPDATE used on a SP.The SP receives 6 parameters: @RecordId, @Col1Value, @Col2Update, @Col2Value, @Col3Update, @Col3Value...Col1 is always updated but Col2 and Col3 are only updated if Col2Update and Col3Update are true ........So is dynamic SQL a good option for this case too?![/quote]The trigger is going to be fired anyway, teh data engine is going to be invoked anyway, the update is going to be logged anyway, because col1 is alwys updated. So having the 2 case expressions in the update statement to generate updates that either do or don't update col2 and col3 doesn't generate any noticeable overhead, may even be cheaper in performance terms than building dynamic SQL. Of course if you have an IF UPDATED(col2) condition in the trigger that wants to know whether col2 was actually changed you have to write it differently, but that is trivial for your update statement (and supertrivial if id is a unique key).Thu, 04 Oct 2012 09:55:11 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxHi,Regarding Dynamic SQL....Instead of a SELECT suppose I have an UPDATE used on a SP.The SP receives 6 parameters: @RecordId, @Col1Value, @Col2Update, @Col2Value, @Col3Update, @Col3Value...Col1 is always updated but Col2 and Col3 are only updated if Col2Update and Col3Update are true (1).Should dynamic SQL be used here as well?I could write[code="sql"]UPDATE table SET Col1 = @Col1Value, Col2 = CASE WHEN @Col2Update = 1 THEN @Col2Value ELSE Col2 END, Col3 = CASE WHEN @Col3Update = 1 THEN @Col3Value ELSE Col3 ENDWHERE Id = @RecordId[/code]but this would make Col2 and Col3 always be updated no matter what, even if the value is themselves...also it's possible to write:[code="sql"]UPDATE table SET Col1 = @Col1Value WHERE Id = @RecordIdIF @Col2Update = 1 UPDATE table SET Col2 = @Col2Value WHERE Id = @RecordId....[/code]This would make another seek and update row and if the table had an UPDATE trigger it would fire the trigger again...Back to the 1st case if there was also a trigger with the condition IF UPDATED(Col2) the condition would always be true...There also the long solution:[code="sql"]IF @Col2Update = 1 AND @Col3Update = 1 ....ELSE IF @Col2Update = 1 ELSE ..... IF @Col3Update = 1..... ELSE...[/code]This is long and if necessary to add another column it would even longer... 2^[optional parameters]..So is dynamic SQL a good option for this case too?!Thanks,PedroThu, 04 Oct 2012 08:09:03 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]L' Eomot Inversé (10/4/2012)[/b][hr][quote][b]Sean Lange (10/3/2012)[/b][hr][quote]... Isn't LIKE as good as >= for index seeks?!?[/quote]NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.[/quote]Actually LIKE is sargable when the pattern expression reduces to matching an initial substring, provided of course the pattern expression is unicode when the column is unicode and not unicode when the column is not unicode; so it doesn't prevent index scans.(I remember thisone because it's half of a weird inconsistency: using LIKE to match an initial substring is sargable, while using LEFT is not ;-))edit:spelling[/quote]Thanks for the clarification Tom.Thu, 04 Oct 2012 07:45:02 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]PiMané (10/3/2012)[/b][hr][quote][b]Sean Lange (10/3/2012)[/b][hr]NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.[/quote]So a LIKE 'M%' is better replaced with a >= 'M' AND < 'N'..[/quote]No, that is wrong! LIKE 'M%' is SARGable, you don't need to replace it with such a mess However, LIKE '%M' is not SARGable!. But replacing it with comparison operators will be quite problematic :-D.If you really need the best possible performance for text searches like the above, there is SQL Server feature called Full Text Search. [url]http://msdn.microsoft.com/en-us/library/ms142571.aspx[/url]It's designed for performing effective comprehensive text searches. Thu, 04 Oct 2012 03:49:11 GMTEugene Elutinhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Sean Lange (10/3/2012)[/b][hr][quote]... Isn't LIKE as good as >= for index seeks?!?[/quote]NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.[/quote]Actually LIKE is sargable when the pattern expression reduces to matching an initial substring, provided of course the pattern expression is unicode when the column is unicode and not unicode when the column is not unicode; so it doesn't prevent index scans.(I remember thisone because it's half of a weird inconsistency: using LIKE to match an initial substring is sargable, while using LEFT is not ;-))edit:spellingThu, 04 Oct 2012 02:37:14 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Sean Lange (10/3/2012)[/b][hr]NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.[/quote]So a LIKE 'M%' is better replaced with a >= 'M' AND < 'N'..Wed, 03 Oct 2012 08:55:26 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote]... Isn't LIKE as good as >= for index seeks?!?[/quote]NO LIKE is not SARGable so you will get scans. It has to examine every row to determine if it is a match or not.Wed, 03 Oct 2012 08:40:52 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxHi,I just made a simple test... I build a dynamic SQL to execute and executed the same query directly in SMSS...Can anyone explain why the dynamic SQL is 46% of total time and the same query but "fixed" is 54%, as shown in the attachment..?!?![code="sql"]CREATE NONCLUSTERED INDEX [idx_Employees_003] ON [dbo].[Employees] ( [empname] ASC, [salary] ASC);[/code]This is the index being used...If I use the "fixed" SQL but "guessing" the parameters, like this:[code="sql"]SELECT empid, empname, salary FROM dbo.Employees WHERE empname >= CASE WHEN LEN(@FilterName) > 0 THEN @FilterName ELSE empname END AND salary >= ISNULL(@FilterSalary, 0)[/code]SQL suggests an index on salary including empid and empname.. If instead of empname >= ... I use empname LIKE ..., on the dynamic SQL, it also suggests the index on salary and include empid and empname... Isn't LIKE as good as >= for index seeks?!?Thanks,PedroWed, 03 Oct 2012 08:17:04 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxThanks to all for the help..PedroTue, 02 Oct 2012 12:47:06 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]PiMané (10/2/2012)[/b][hr]Thanks... using the column number isn't as much readable friendly as is the column name.... but it works fine :-)Is there any problem using the column number besides risking adding a column to the query and messing the order and not being so friendly?!Thanks,Pedro[/quote]It will work but referring to columns by ordinal position is fraught with maintenance issues. You have already defined the problem. The query changes and the person making the change doesn't know or even think about the order by variable stuff going on.Tue, 02 Oct 2012 10:59:20 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxThanks... using the column number isn't as much readable friendly as is the column name.... but it works fine :-)Is there any problem using the column number besides risking adding a column to the query and messing the order and not being so friendly?!Thanks,PedroTue, 02 Oct 2012 09:51:55 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxif you know where the column that you want to Order By, sits, you can do[code="sql"]selectcol1,col2,col3from tablenameorder by 1[/code]this will order by the first column.change it to 'order by 2' to order by the second columnTue, 02 Oct 2012 09:36:22 GMTdavidandrews13http://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspx[quote][b]Sean Lange (10/2/2012)[/b][hr]You should read this article from Gail about catch all queries. [url=http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/]http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/[/url][/quote]Thanks, I've read it and it answers my question...But is there a way of having a dynamic ORDER BY with CASE clause without having N order columns?![code="sql"]ORDER BY CASE WHEN @ordfld = 1 THEN MoneyField WHEN @ordfld = 2 THEN NameField END[/code]this raises an error.. it has to be written[code="sql"]ORDER BY CASE WHEN @ordfld = 1 THEN MoneyField END, CASE WHEN @ordfld = 2 THEN NameField END[/code]which makes 3 order by clauses when I only want one, even if they can be NULL...Thanks,PedroTue, 02 Oct 2012 09:00:40 GMTPiManéhttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxYou should read this article from Gail about catch all queries. [url=http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/]http://sqlinthewild.co.za/index.php/2009/03/19/catch-all-queries/[/url]Tue, 02 Oct 2012 08:39:18 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1366489-392-1.aspxHi,I'm doing some testing with dynamic filtering and order by clause.I'm comparing dynamic SQL vs using the CASE statement...[code="sql"]DECLARE @FilterName NVARCHAR(100) = 'M%'DECLARE @FilterSalary FLOAT = 3000DECLARE @OrderField INT = 0 --0 empname, 1 salary, 2 - empidDECLARE @Query NVARCHAR(500)DECLARE @Params NVARCHAR(500)SET @Query = 'SELECT empid, empname, salary FROM dbo.Employees WHERE 1 = 1'SET @Params = '@FilterNameIn NVARCHAR(100), @FilterSalaryIn FLOAT'IF LEN(@FilterName) > 0 SET @Query = @Query + ' AND empname LIKE @FilterNameIn'IF LEN(@FilterSalary) > 0 SET @Query = @Query + ' AND salary > @FilterSalaryIn'IF @OrderField = 0 SET @Query = @Query + ' ORDER BY empname'IF @OrderField = 1 SET @Query = @Query + ' ORDER BY salary'IF @OrderField = 2 SET @Query = @Query + ' ORDER BY empid' EXEC sp_executesql @query, @Params, @FilterNameIn = @FilterName, @FilterSalaryIn = @FilterSalarySELECT empid, empname, salary FROM dbo.Employees WHEREempname LIKE CASE WHEN LEN(@FilterName) > 0 THEN @FilterName ELSE empname ENDANDsalary >= ISNULL(@FilterSalary, 0)ORDER BY CASE WHEN @OrderField = 0 THEN empname END, CASE WHEN @OrderField = 1 THEN salary END, CASE WHEN @OrderField = 2 THEN empid END[/code]Initially I tried [code="sql"]ORDER BY CASE WHEN @OrderField = 0 THEN empname WHEN @OrderField = 1 THEN salary WHEN @OrderField = 2 THEN empidEND[/code]To order by only one column but since the fields have different data types SQL gave an error. I could do a CAST but salary as NVARCHAR doesn't give good results... So I used the 3 columns sort..... In both cases the execution plan is very similar, the CASE statement has a Compute Scalar with 0% (from the CASE statement)...But if I order by the 3rd column ( = 2) to non dynamic statement, according to execution plan comparing both, is much "heavier" since it orders by 2 NULL columns and only then by the desired column....Is this a case where Dynamic SQL can be used, where it's better than "regular" SQL statements?Thanks,PedroMon, 01 Oct 2012 05:16:01 GMTPiMané