Viewing 15 posts - 52,081 through 52,095 (of 59,091 total)
Yes, but it will take longer... you can do it with a Tally table and a join on the backslashes using SUBSTRING. I've already tried it (damn... should have...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:54 am
Heh... I can tell you which one is the only one that works 100% of the time...
http://blog.pengoworks.com/index.cfm/2008/2/15/The-only-valid-measurement-of-code-quality-WTFsminute
:hehe::P:D:);)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:49 am
Heh... Hour or so? Like I said previously, I've used this method to do 5.1 million rows in about 3 minutes. I'm sure there's a faster method, but...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:48 am
Heh... Daniel, unless you're wearing a porkchop around your neck, everyone is welcome in the "lions pit". Nice code...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:42 am
Sharon Matyk (1/3/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:40 am
CRUD... for some reason, this thread will no longer allow me to add a reply... in fact, it keeps overwritting THIS message when I try and the previous message has...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:36 am
Nisha, it depends... is the code for high hit ratio GUI code or is it for batch code that runs every once in a while?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:29 am
SELECT/INTO hauls butt in any DB but it runs like an ape that sat on a hot coal if you use it on a database that is setup for anything...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:24 am
Heh... WELLLLLLLLLLL!!!!!!
I'm pretty sure all you need is one select per column per table. It there where some rhyme or reason to the table names you
wanted to attack, we...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 6:03 am
Grant Fritchey (3/5/2008)
What this is doing is using the temp table in place of a join or joins. That's bad.
Ummm... I gotta say, "Not always". I've used temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 5:17 am
Nicely done... there are a couple of things I do exactly the opposite of you, but if I were working in your shop, the rules you wrote are pretty easy...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 5:07 am
Ok...when a shopper logs in, what are the key field(s) that are looked at in the "old" table? Also, how long is it currently taking to validate the shopper?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 4:52 am
Thats one of the better ideas, Ralph. It takes 25 ms duration, 15 ms CPU time, and 214 logical reads.
The update method I showed, as long as it looks,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 4:47 am
My thoughts, exactly... next question would be... when is VARCHAR(MAX) in an "in row" condition? I'm thinking the answer, unlike the TEXT datatype can be forced to be, is...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 4:33 am
Well... maybe a little evil 🙂 It is a good "tie breaker" question.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 6, 2008 at 4:31 am
Viewing 15 posts - 52,081 through 52,095 (of 59,091 total)