Viewing 15 posts - 58,981 through 58,995 (of 59,067 total)
I dunno... call me "old school"... This will always round up to the base as well.
SELECT ROUND(@Value/@Base+.499999,0)*@Base
Also, just curious... why would you need to round up to...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 9, 2004 at 11:44 pm
Sukio,
Like I said in one of your previous posts, lookup "expanding hierarchies" in "Books on Line". With a minor amount of tweeking, it will do exactly what you want.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 31, 2004 at 9:11 am
Rohit,
The setbased logic you used in your example will almost always beat Cursors and WHILE loops. Do you need any reason other than speed? Ok, how about resource intensity, duration...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2004 at 9:37 pm
Sukio,
There is an example query in "Books on Line". To find it, lookup "expanding hierarchies" in the BOL index. Be advised that it is not "bug free" and will require...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 30, 2004 at 9:13 pm
--Jeff Moden
Change is inevitable... Change for the better is not.
May 29, 2004 at 9:59 pm
This should do it with some assumptions... the assumptions are that you will have no title (Mr., Mrs., etc) and no suffic (Jr. Sr. II, III, IV, etc).
/******...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 23, 2004 at 8:59 pm
David,
If Edward is correct and all you really want is to split the last name from the rest and we assume that the last name will appear after the last...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2004 at 6:27 am
You have to convert @Count to VARCHAR or CHAR
--Jeff Moden
Change is inevitable... Change for the better is not.
May 21, 2004 at 4:58 am
Hi Midan,
Guess there might be a little problem with the language barrier thing... let me see if I can clear it up...
I believe your problem is that you want to...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 6:56 am
Sukhoi,
I don't know if the little bit of "language barrier" between us is a problem or if I'm just misreading this... just want to make sure you aren't stepping onto...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:38 am
Sukhoi,
Again, as in the post I answered for you previously, you need to do some conversions in the concatenization. You have to CONVERT the date to VARCHAR or CHAR. See...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:29 am
Sukhoi,
It's funny how the error message is sometimes the opposite of what it should be...
Your problem is that the contents of one or more of your variables are numeric and...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2004 at 5:24 am
You never mentioned how long it was taking for the update...
My experience for these two table type of single column update joins says you'll get about 4 million rows...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2004 at 5:32 pm
paolice,
Understood... I use "trial and error" a lot. But you still haven't given me a clue as to how to use DataLength to determine the defined length of a column. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2004 at 5:18 pm
Thanks Antares... didn't know that.
Hey paolice... how do you get DataLength to return the "defined length of your table's columns"? Couldn't find a thing about that in BOL.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 18, 2004 at 5:42 pm
Viewing 15 posts - 58,981 through 58,995 (of 59,067 total)