Viewing 15 posts - 51,976 through 51,990 (of 59,067 total)
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
chris.compton (3/7/2008)
It is my understanding that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 8:15 pm
The assembly (dll) just calculates the companies holidays.
Curious... did you know that a T-SQL function will likely run just as fast here and a properly formed Calendar table will out...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 4:13 pm
I missed that in Adam's post (too much of a hurry). He's absolutely correct.
Only problem is, this is an SQL Server 2k post... Adam's solution uses VARCHAR(MAX) which isn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 4:07 pm
All right smarty....He's pointing at the BOL entry for OPENQUERY...
Heh... truth be told, I didn't even look once he said it was in Spanish.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 4:02 pm
Ray White (3/7/2008)
IE I would like 0.4567 vs .4567; The only way I can think of doing this is to...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 7, 2008 at 3:57 pm
Viewing 15 posts - 51,976 through 51,990 (of 59,067 total)