Viewing 15 posts - 58,576 through 58,590 (of 59,099 total)
No need to be sorry... most of us have made the same mistake early in our SQL careers. Those that say they didn't... are lying. ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 11:37 pm
Sure, one complete explanation coming right up... but I'm a bit surprised you didn't figure it out yourself... remember, you asked the question...
First, I modified your code so we could...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2005 at 11:04 pm
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
Viewing 15 posts - 58,576 through 58,590 (of 59,099 total)