Viewing 15 posts - 58,441 through 58,455 (of 59,067 total)
set @sPool = 'w' + RTRIM(@sPool) + 's'
print @sPool
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 10:34 pm
Dang... didn't read the post close enough... my apologies for the previous lamer post.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 4:51 pm
To add to my previous, RayM's answer is absolutely correct. Further, if you have to do such a thing on a hundred thousand rows to send as a file, then...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 7:19 am
I really wish people would stop saying that... sometimes SQL is the only client application you have.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 7:11 am
Jennifer,
Contrary to what many have posted above, there is absolutely nothing wrong, not even the thing about the aliases, with your code. It is very likely a simple matter of...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 7:07 am
As you are aware, performing just about any calculation on an indexed column will negate any chance of using the index. Try this... it's simple and makes for nasty fast...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 25, 2006 at 6:54 am
First, using a cursor
or a WHILE loop
just isn't an option for me... I just gotta do...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 24, 2006 at 8:06 pm
John and Jeffrey,
Thank you both for taking the time to read the post and understand it
Don't be too disappointed if you can't...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 24, 2006 at 5:12 pm
Then, I'm thinking that someone didn't design the database correctly. It's hard for me to believe that anyone would make a permanent table that has over 520 some odd...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2006 at 10:24 pm
"SELECT INTO" is actually a setting called "SELECT INTO/BULK COPY" and it does NOT disable the ability to use the SELECT/INTO syntax. It just means that it will be logged. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2006 at 10:20 pm
Jeffrey,
First, I say "you" a lot in the following write-up... I don't mean you personally and hope you don't take it that way (personally). Your questions are outstanding and instead...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2006 at 9:57 pm
I believe the reason why the Numbers or Tally table solution is so much faster is two-fold.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2006 at 6:18 am
If your going to post things like this, you might also take the time to post the reasons ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 23, 2006 at 5:34 am
Jeffrey,
As you are probably aware (you ARE an experienced CIO), any RBAR (a "Modenism" for "Row By Agonizing Row", pronounced "ree-bar") is ALWAYS slower than an equivalent set-based operation. Cursors...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 22, 2006 at 12:52 am
What is the datatype of the column you call "Activity Date"? I have the sneaky suspicion that it's not a DateTime column and need to know what datatype it is...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 21, 2006 at 11:57 pm
Viewing 15 posts - 58,441 through 58,455 (of 59,067 total)