Viewing 15 posts - 35,401 through 35,415 (of 59,099 total)
GSquared (1/13/2011)[hrUpdate From can have problems if it runs into two or more rows that match the Join/Where criteria and would update one row in the target table. Same...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 13, 2011 at 8:03 am
Steve Jones - SSC Editor (1/12/2011)
I think that green is an appropriate color for the US
It would be nice if they kept them Green. Have you seen how much...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 9:07 pm
Steve Jones - SSC Editor (1/12/2011)
As my friend Jeff would say, Bwaa-haa-haa
BWAA-HAAA!!!! Now THAT's some funny stuff right there. Thanks for the laugh, Steve! ๐
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 9:00 pm
mister.magoo (1/12/2011)
DECLARE @exampleString xml
SET @exampleString = ' <result>failure</result> <reason>invalid Phone1</reason> <leadId>xxxxxxxxxxxx</leadId> <url><![CDATA[https://blahblahblah]]></url>...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 8:57 pm
WayneS (1/12/2011)
Jeff Moden (1/12/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 8:51 pm
WayneS (1/12/2011)
Mark-101232 (1/12/2011)
Changingvalue('.','varchar(max)'),1,1,'')
to
value('(./text())[1]','varchar(max)'),1,1,'')
appears to give a better query plan
Thanks for the information... I'll have to test this out.
Edit: WOW! What a difference!...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 5:54 pm
CELKO (1/12/2011)
Using BIT is bad and a NULL bit makes no sense. Using the proprietary UPDATE..FROM.. syntax has lots of problems with cardinality and portability.
I don't care about portability but...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 4:37 pm
BaldingLoopMan (1/11/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 4:26 pm
Also, table variables don't necessarily make things any faster than a Temp Table. They both start out in memory... they both write to disk (TempDB) when they get bigger...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 12, 2011 at 7:16 am
Heh... it's not as easy as it looks, huh?
Thank you for setting up the sample data correctly. This should do it for you... the CTE's are named after what...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 7:42 pm
david.alcock (1/11/2011)
I passed my 070-431 yesterday, absolutely delighted.
My question is about the upgrade MCITP exam. Im hoping to do 443 &...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 7:19 pm
zahidullislam (1/11/2011)
Can anyone please help me to (Pseudocode will be perfect) to translate below query to SSIS steps?
My Data Source is is Raw file and output will be in Raw...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 7:17 pm
tfifield (1/11/2011)
Jeff Moden - 1/10/2011
Why can't you just add the IDENTITY property to the UNQ_ID column? It will help you avoid a whole lot of headaches including but certainly not...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 6:52 pm
Also (just and FYI), during INSERTs, it could also be too many indexes or an index with extremely low cardinality. For example, any index where the first column has...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 6:36 pm
Lowell,
If you want to "continue the tradition" on these short articles, please feel free to use the "SQL Spackle" idea and the quote from "Phil McCraken". I've found it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 11, 2011 at 9:59 am
Viewing 15 posts - 35,401 through 35,415 (of 59,099 total)