Viewing 15 posts - 55,741 through 55,755 (of 59,072 total)
Heh... I was trying to think of a way to prove some of the bad experiences I've had with some programmers using UDF's for everything... then I checked my email...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 7:45 pm
I've not had to work with Accent words so I'm not 100% sure... if I remember correctly, though, take a look at "Collation" in Books Online... seems like I remember...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 7:27 pm
Not to worry... considering the situation you said you're in, I absolutely don't blame you especially in the absence of anything else in my rather one-sided first post. I'm in...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 7:20 pm
Ok, folks... I don't get it... why does everyone keep adding when they should be multiplying???
Using Peter's modified algo which returns .95...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 6:53 pm
I just make sure I do a copy of everything in the reply window before I hit submit... I learned that "posting" lesson on this and other forums... kinda like...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 8:37 am
Heh... that's what I get for playing devil's advocate and I should have explained more...
Thanks for filling in the details. 
--Jeff Moden
Change is inevitable... Change for the better is not.
July 18, 2007 at 8:33 am
Give me Info on how the two rows relate to each other
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 10:15 pm
Kinda busted a hump trying to help you get rid of the cursor on this one, Joel... any feedback? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 10:13 pm
Not sure you need that many conditions even to accomplish the 3rd condition... this should do the trick...
select count(t1.intID --Jeff Moden Change is inevitable... Change for the better is not.
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)
July 17, 2007 at 10:09 pm
Vijaya,
Since you're brand new, lemme just tell you that posting data in the following manner is much more helpful to those that would help you... tell's us almost everything we...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:55 pm
Just from the practical point for ease of troubleshooting, here's from our "standards" book at work...
All column names shall be prefixed with a table alias in the presence of joins...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:18 pm
Phill is spot on. I'll kick in that BCP has some additional features that make it a bit slower than Bulk Insert (but still faster than DTS) including error logging...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 9:09 pm
It's not often that I see a query improve performance by applying Index Hints. Usually, it's the other way around... When you say you are seeing some impressive improvements in...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 6:07 pm
Lookup sp_Rename in Books Online... that'll do what you need...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:58 pm
... and, that's just the date... doesn't include time...
But, Serqiy is correct... there's a date format that's based on the number of seconds since the 01/01/1970. There are other "numeric" date...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 17, 2007 at 5:53 pm
Viewing 15 posts - 55,741 through 55,755 (of 59,072 total)