Viewing 15 posts - 53,131 through 53,145 (of 59,089 total)
That's one of the best compliments anyone could ask for, James. Thank you, Sir!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:16 pm
14k characters? What on earth are you doing?
Still, Exec will handle many more than 14K characters... so that's not the problem. Can't tell what's causing the problem 'cause...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:12 pm
Please share what you did...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:03 pm
Both will take the same time because EM7 will run the same code as what you've typed behind the scenes...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:57 am
Yes, thank you for the feedback and I agree that a clustered index will, in fact, make the concatenation run much faster... except that most folks aren't going to dedicate...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:55 am
So...are you saying I can have a procedure do what this functions does?
Well, kind of... before SQL Server 2000, there was no such thing as user defined functions... people ended...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:16 am
Since there is no need for dynamic SQL in this case, just remove the quotes from the variable names... like this...
ALTER PROCEDURE spgetemp
@empname varchar(30),
@jdate datetime
AS
SET NOCOUNT ON
insert into #t exec...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:11 am
Heh... Mom always said, "Never run with scissors"... being in a hurry on code has the same effect on careers.
Anyway, glad you figured it out... and thank for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 7:05 am
Awesome... thanks for the feedback, Derek!
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 6:57 am
Unless none of your dates have times on them, the original query and the replacement query are bad...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 12:34 am
No...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 12:32 am
You're missing the point... you will not get all of 01/04 using BETWEEN...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 4, 2008 at 12:22 am
Not sure why you're whackin' at me on this one, Gail... real fact of the matter is that 4 million internal rows were generated and they don't show on the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 11:40 pm
No... it's not perfect if you want to include the whole day of 01/04/2008...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 11:26 pm
No, they won't. At best an exec plan shows the number of rows that each operator accepted, processed and returned, but that's the number of rows in the result set,...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 11:24 pm
Viewing 15 posts - 53,131 through 53,145 (of 59,089 total)