Viewing 15 posts - 58,966 through 58,980 (of 59,063 total)
Cedar72,
You've been bitten by the "time" element of datetime data types... try this as your WHERE clause...
The DATEADD/DATEDIFF thingy accurately removes...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2004 at 9:51 pm
Jana,
Yeah, before you say anything, I see the bug, too. Here's the corrected code... had to assume that you would have something in first name and last name fields to...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2004 at 9:29 pm
Jana,
Here's a real simple solution using the power of a NULL being returned when a NULL is concatenated... the key is to concatenate each space or comma with each name...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2004 at 9:19 pm
Regardless of which method you use to do the renumbering, if Col1 is an IDENTITY column, you would need to include the following line just before the update...
SET IDENTITY_INSERT tablename...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 16, 2004 at 6:05 am
I dunno... David Burrows' solution doesn't use CONVERT or any form of overt concatenization (+) and may be faster as a result. In the beginning, I used LEN, then graduated...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2004 at 9:51 pm
Dummy me... missed the formatting thing... thought he didn't understand the "ELSE". Nice job, Rockmoose!
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2004 at 3:21 pm
Rockmoose,
>We do have a problem if they have breaks around midnight .. though
Yeah, I had the same problem and decided that it wasn't so bad to use a temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2004 at 3:14 pm
Sukhoi,
I can't post back to your original post, either... I did take a look at the code you posted and all I can say is ...
Daaannnnng that's a lot of...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2004 at 9:46 am
Not sure from your description of the problem but I think an INSERT statement would probably do... since you didn't mention which 3 parameters you wanted to save nor which...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 12, 2004 at 9:32 am
@F3 was greater than one so the ELSE prevails giving you the exact same answer as you had in your second example.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 11, 2004 at 11:30 pm
Barsuk (heck of a handle there),
First, I hope your times look like 12:30 and not 12.30 or we'll have to do a bit more wittling...
The key to the problem is...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 11, 2004 at 11:19 pm
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
Viewing 15 posts - 58,966 through 58,980 (of 59,063 total)