Viewing 15 posts - 58,051 through 58,065 (of 59,067 total)
Agreed... a little more info would help... should it be a date, and sequential ID, what???
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 9:46 pm
Rodger,
Did anyone change the default datatime format on the non-production box?
This is why you should not trust defaults... things change.
Perhaps, if you posted the code, we may be able...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 9:32 pm
Keith,
Yes, there's an easy way and it does NOT require the overhead of a cursor...
Substitute the name of yourtable for "yourtable" everywhere in the code below...
First, make a function...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 9:23 pm
I', a bit confused... you know the number should always come in having 5 decimal places but you want to convert VARCHAR to INT and you ultimately want to "do the...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 9:04 pm
Try not using a cursor
...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 9:00 pm
Thanks, Bill,
I do have to emphasize that performance will usually be better if you do this simple type of thing in the code mainstream instead of a function. Functions are...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 8:58 pm
Jules,
The two functions I wrote do get rid of the time portion and they do it with only trwo functions instead of the 5 you used. AND, they did it without...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 8:55 pm
My recommendation would be not to make a trip to a character based date and back again... I'd also not make a stored procedure for it. I'd likely do it...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 2, 2006 at 12:23 pm
Dunno about VB datetimes but in SQL Server 2000...
I think you'll find that 23:59:59.999 will round up to precisely 00:00:00.000 and that 23:59:59.998 will round down to 23:59:59.997.
SELECT CAST('23:59:59.999' AS DATETIME)
SELECT CAST('23:59:59.998' AS...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2006 at 6:57 am
I agree... a decent article... but it DOES sound like an advertisement and provides no real info as to how to do the sizing estimate if you don't have those...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2006 at 5:59 am
Not a problem, Nick. You had the right idea...
In SQL Server (very cool and very unlike Oracle), there are two tables that are temporarily formed (in TempDB) and available in...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 30, 2006 at 5:50 am
Nicely done... a couple of minor things you may want to change...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2006 at 9:33 pm
I haven't checked your logic but the problem with the triggers is that they are written in a RBAR (pronounced "ree-bar", my less than affectionate term for "Row By Agonizing...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2006 at 7:40 pm
I think someone needs to look at the data in the tables. How many times is a ZipCode listed in the neigborhood Profiles table? You could be spawning dozens or...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 29, 2006 at 4:54 am
Scott's method will certainly work! I'd still like to know why "net" wants to do this...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 28, 2006 at 3:15 pm
Viewing 15 posts - 58,051 through 58,065 (of 59,067 total)