Viewing 15 posts - 58,546 through 58,560 (of 59,067 total)
Don't use sp_Execute. Just use EXEC...
EXEC (@SQL1+@SQL2+@SQL3....+@SQLn)
... and each of the variables can be VARCHAR(8000).
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 10:13 pm
dba321,
The Inserts that Phil provided are just test code to simulate your much larger table (or result set, whatever)! You don't need any of those Inserts and you certainly don't...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 10:04 pm
You certainly don't need a cursor and, if you don't want, you don't need a function... "Trust the force, Luke."
SELECT CONVERT(VARCHAR(10),SecondsCol/86400)+':'
+ CONVERT(VARCHAR(8),DATEADD(ss,SecondsCol,0),108)
FROM yourtable
The forces to...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2005 at 11:08 pm
I don't think he meant to be sarcastic... he was just having fun and beat most of us to it. It's hard to tell in email when someone is joking...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 13, 2005 at 9:18 pm
It's customary to share your final solution, if you don't mind.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2005 at 7:05 pm
Jon,
David is correct... since Julian dates recycle every 10 years, should we assume that you will never have a future dated Julian date?
Also, would you rather (recommended) have the date...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2005 at 7:02 pm
David is correct... his link leads to some code I wrote for him to make a "dynamic" cross-tab. Might have a fat-finger here and there but David wrote and posted...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 12, 2005 at 6:05 pm
Jennifer,
Since you want this done in OLTP instead of OLAP, these are more commonly known as "crosstabs" and they run pretty darned fast especially when compared to a cursor and...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2005 at 9:57 pm
With all the good solutions, I feel a little silly posting this but it's nasty fast... and, since a lot of folks keep their Tally (numbers) tables down to something...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 11, 2005 at 2:01 pm
Defaults don't work on rows that have already been inserted. Leaving it up to Developers to remember to include it in code is OK provided the code has to go...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2005 at 10:13 pm
Thanks for the nice things you said, David. Surprisingly enough, I don't believe you'll find a huge performance gap just because of the use of the Dynamic SQL. Dynamic SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2005 at 10:18 am
BWAAAA-HAAAAA-HAAAAAA-HAAAAA! I just ran the same set of tests on a 4 processor box "real server" with minor traffic for 2,000,000 records using my previous test code and the differences...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 10, 2005 at 10:09 am
Ok, so does that short-term bottleneck stuff explain why my latest test consistently showed that the UDF code was twice as slow as the clear code regardless of the number...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 5:25 pm
Vladan and Sushila are correct... you may also just try finding the first day of the next month and the looking for anything less than that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 5:21 pm
Just keep in mind, David... it breaks at 8k... I think that won't happen for quite some time, though.
Manchester UK, eh? I've always wanted to see that place... I may...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 5:10 pm
Viewing 15 posts - 58,546 through 58,560 (of 59,067 total)