Viewing 15 posts - 58,561 through 58,575 (of 59,081 total)
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
Exec sp_Locks
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 12:26 am
Viewing 15 posts - 58,561 through 58,575 (of 59,081 total)