Viewing 15 posts - 54,811 through 54,825 (of 59,098 total)
Hey there PoleCat... long time no "see"...
Is it the goal of this bit of code to update all but the "first" row for each customer what has been entered within...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 11:06 pm
Sergiy (9/28/2007)
Un-bloody-believable!How could possibly a dude having no idea about binary get any job in IT industry???
BWAAAAA-HAAAAAAA-HAAAAAA!!!! Oh, stop it! You're killing me!!! 😀 They don't even...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 10:22 pm
Transactions??? Why do you need transactions for this??? That's the problem....
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 10:03 pm
A little exuberant on Remi's part... but I absolutely agree with Serqiy and Remi... writing to system tables is a form of "Death by SQL"... you will make a mistake...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 10:01 pm
I got the following from a fellow by the name of "Jeff Smith"... it's pretty much spot on and is a long winded version of what Serqiy posted, which is...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:54 pm
OMG!!! Table driven code! What a concept 😉
Nice job, Serqiy...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:43 pm
Paul (5/3/2007)
Make believe that this has nothing to do with cursors, stored procs or anything else. I just want to know if anyone has ever seen...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:39 pm
Steve Jones - Editor (9/28/2007)
Ouch!Noted and added to the list.
Heh... when are they going to get to the list I submitted, Steve?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:31 pm
Bob Fazio (9/12/2007)
The following does a much better job explaining when/why to use table variables.
Also, be careful not to get into optimization overload. I still suggest that you spend...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:26 pm
Normalize 'til it hurts! It'll save lot's of pain later on... kinda like the pain you're going through right now... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:21 pm
Ninja's_RGR'us (9/29/2007)
Wow, 52 gig of space!!!! That's a lot of crap to put up with ;).
Ouch! Brain freeze! You just reminded me of a girl I used to...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:16 pm
GilaMonster (9/29/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:11 pm
Did someone say "loop"??? :blink: On a single row????? :sick:
Using a previous example where 5 decimal places are required to be padded with zeros...
DECLARE @i DECIMAL(10,5)
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:06 pm
Sorry... temporarily lost my mind... I meant CreatedBy and CreatedOn... not "Modified". 🙂
You think it's better to store all data twice on insert?... Once "normal sized" in the original...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 8:53 pm
Thanks, Bob...
First, updating 500K or even a million rows in a single update probably isn't a problem... 20 million is a problem. If you do some testing, I think...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 4:20 pm
Viewing 15 posts - 54,811 through 54,825 (of 59,098 total)