Viewing 15 posts - 50,356 through 50,370 (of 59,099 total)
RyanRandall (5/22/2008)
drop table #Results
; with a as (select RowNum, cast('<parm '+ replace(replace(Parameters,'=','="'),'&','" ')+ '"/>' as xml) as Xml from #SourceTable)
select RowNum,
Xml.value('(parm[1]/@Subject)[1]', 'varchar(255)') as Subject,
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 6:33 pm
No problem... quick look says they all suffer from the same problems and all are in need of a major rewrite.
Heh... Kevin... I'm right there with you... I've recently been...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 6:30 pm
Looks like you got it... Thanks for the feedback and for posting your solution.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 6:22 pm
jcrawf02 (5/22/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 5:55 pm
Obscenotron (5/22/2008)
Freakin' awesome article, man. I had no idea such things as these existed. I have seen the light. Thank you!
Now THAT's an awesome compliment! Thanks!
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 4:27 pm
It would really help if you did two things...
1. Post what the actual error is
2. Post the generated conten of the dynamic SQL code
You may even want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 4:13 pm
You need to define what a "week" is before anyone can help... Do weeks start on a Monday or ??? Are you talking about ISO week #'s or SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 22, 2008 at 4:10 pm
My pleasure. Thank you for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 11:33 pm
Wayne,
Take a look at the following URL and warp the technology to do exactly what you need...
http://www.sqlservercentral.com/articles/Advanced+Querying/61716/
It will be nasty fast... methods used will take care of a million rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:59 pm
Not good... you can get dupes that way because of the relatively narrow INT range that CHECKSUM offers compared to the binary range of NEWID()... here's the proof of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:50 pm
No problem. Thank you for the feedback.
Generally speaking, folks like to see running balances on their monthly reports. Take a peek at the following article for a super...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 10:08 pm
wgarces,
See the following article... it covers this type of concatenation and a couple of related pitfalls to avoid...
http://www.sqlservercentral.com/articles/Test+Data/61572/
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:41 pm
I don't believe that works the way the OP posted... that will only give 1 employee name per company.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:40 pm
So... did it? 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:34 pm
Yep... move the process to a data base that uses the SIMPLE recovery mode. If you don't have one... make one... call it "ScratchPad" or "SandBox" or something like...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2008 at 9:32 pm
Viewing 15 posts - 50,356 through 50,370 (of 59,099 total)