Viewing 15 posts - 52,651 through 52,665 (of 59,091 total)
I don't think I wrote an article on "DateDiff Usage"... so it would be interesting to find out how my name got on this...
Anyway, nice trick you've found. I...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 6:06 pm
And, maybe learn how to post sample data to get better answers...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 5:53 pm
Heh... right there with ya, Gus... seems like the long way to spell "Death by SQL", though 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 5:39 pm
That should do it... nicely done, John.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 5:07 pm
You said that you wanted to pass parameters to the stored procedure in the trigger. That smacks of RBAR and single row processing which is a form of "Death...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 5:05 pm
Then, you need to post the exact code you're getting the error with and the exact error... because the code I posted gives no such error on my machine. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 4:08 pm
Radovan Jablonovsky (2/8/2008)
If it is possible in your production environment to dynamically change number of processors, then it is OK. In our environment it is more conservative, therefore I am...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 4:04 pm
I absolutely agree, Matt... same thing goes with the SUM() OVER... they (MS) don't allow the necessary ORDER BY to calculate a running total using SUM() OVER like they do...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 7:10 am
Which error? The one about conversion from char to date producing an out of range value? And, even if you fix that, you'll still end up with a...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 8, 2008 at 7:06 am
VARCHAR(MAX)
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 8:26 pm
Philippe Cand (2/6/2008)
This article is getting unprecedented proportions.
How could we have MS SQL engine development database guys participating in the discussion If they are not yet already doing so...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 8:00 pm
Radovan Jablonovsky (2/7/2008)
Replay for Jeff,Server was setup to use 2 CPU for parallelism and query execution plan showed parallel execution was used in sorting index. See attached pictures.
Sincerely,
Radovan Jablonovsky
Amazing... I've...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 7:57 pm
Adam Haines (2/7/2008)
Good solution Jeff, simply amazing. 😉
Thanks, Adam :blush:
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 7:26 pm
Just a couple of suggestions, folks...
First, there is no need for a loop in the creation of a "Tally" or "Numbers" table. Second, to be truly effective and to...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 6:56 am
Yes... the solution is posted above... the server must be logged into the domain as a user that can actually "see" the file path.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 7, 2008 at 6:18 am
Viewing 15 posts - 52,651 through 52,665 (of 59,091 total)