Viewing 15 posts - 52,006 through 52,020 (of 59,102 total)
Yep. This is exactly what I meant. It runs once per each returned row from the main query. In my tests I was running FOR XML one...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 7:37 pm
rbarryyoung (3/8/2008)
FYI, varchar based date/time columns virtually always have bad data in them.
Nary a truer word spoken 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 7:31 pm
Good article... thanks for posting it. Just about anything by Adam is worth a look-see.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 7:08 pm
That's exactly what I was talking about... you asked why I would use something that I knew was slower... I knew that for the application I wanted, it would be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 6:46 pm
One more thing... you left an extra comma at the end of your two outputs 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 5:42 pm
Almost forgot... here's the output when STATISTICS IO is ON... "Ugly trick" method beats the hell out of the XML method... 😀
[font="Courier New"]================================================================================
"Ugly trick" code...
Table 'TestData'. Scan count 1,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 5:36 pm
Adam Haines (3/8/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 5:16 pm
Yes... I was taking about the Developers Edition of SQL Server 2005.
Oracle experience? I've seen a fair number of people go from Oracle to SQL Server only...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 12:51 pm
Robert (3/8/2008)
Custom aggregates are extremely useful feature. While lists can be done with "FOR XML PATH", some thing can't, like when you have to do a binary OR...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 12:40 pm
A nicer and faster solution that works on SQL Server 2005 and later is one that Robert has linked to
Which of the many solutions are you refering to? There...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 11:27 am
In fact... here's your first homework problem... write the SQL to count from 1 to a million and display each count. Provide three different solutions and discuss the pros...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 11:19 am
There's a recruiting company called TEK and they have a nationwide footprint. Go talk with them... tell them what you told us. They'll find you something. Also, check...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 11:16 am
I believe the issue is with the poor I/O performance,
I agree with Jack, but I'll say it a differnet way... WHY do you believe that? What proof do you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 9:35 am
GilaMonster (3/8/2008)
The only thing I can find on storage of Varchar(max) is that 'SQL decides' (Inside SQL Server 2005: T-sql Programming)
Apparently, it decides wrong... a lot! 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2008 at 8:58 am
Outstanding primer on VBS and the FSO... well done.
I don't know if I missed it in the article, but for anyone that hasn't used it before, you should have said...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 9:00 pm
Viewing 15 posts - 52,006 through 52,020 (of 59,102 total)