Viewing 15 posts - 53,146 through 53,160 (of 59,098 total)
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
Heh... I use the Mil-spec Mark I Mod I Grey Matter Data Integrator... works everytime and any costs incurred can be simply resolved by a good night's sleep and maybe...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 10:07 pm
It's because you're converting the dates to text... try this, instead...
SELECT * FROM [MyDateTable]
WHERE StartDate >= '02/01/2007'
AND StartDate < '01/05/2008'
Notice that the "<" is in relation to the NEXT...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 10:01 pm
p.s. I just noticed that I left the code in that creates the "Raw2" table... that code is just not necessary and may be removed. Sorry for the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 9:50 pm
Ok... sorry for the delay... couple of things came up and I couldn't get back to this... a shame, really, because this was kind'a fun.
In order to split the...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 9:48 pm
Did you use Clustered or Non-Clustered?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 7:25 pm
Check the spelling of @StartTime in the proc... notice... 2 "T's" in your exec... does it have 2 "T's" in the proc?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2008 at 7:11 pm
Viewing 15 posts - 53,146 through 53,160 (of 59,098 total)