Viewing 15 posts - 58,591 through 58,605 (of 59,099 total)
Vladan and Sushila are correct... you may also just try finding the first day of the next month and the looking for anything less than that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 5:21 pm
Just keep in mind, David... it breaks at 8k... I think that won't happen for quite some time, though.
Manchester UK, eh? I've always wanted to see that place... I may...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 5:10 pm
Exec sp_Locks
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 12:26 am
Don't fight 'em... don't tell 'em... put triggers on the tables for these. Most developers don't even know how to spell trigger never mind go looking for them.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 9, 2005 at 12:24 am
Ummmm.... since when is 12/01/2005 a month end date?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 11:45 pm
Good thinking Chandra. I'll have to try it that way sometime because it looks like a really good idea especially since it wouldn't have the 8k limit in the method...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 11:39 pm
Tom, ya got lucky... as Sushila stated, most don't read down a thread this deep especially when Sushila and Mike are having a cyber reunion ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 10:32 pm
Running out of numbers? It can't be because of SQL... BIGINT is H-U-G-E! You could just change the datatype of the column and, bingo, more numbers.
If the restriction is because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 10:08 pm
BANG!
I'm dead. You guys finally proved your point with some cold, hard facts. I didn't like Carl's test the way it was because...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2005 at 9:43 pm
Greg Wrote: Go ahead and use your Scalar UDFs on large datasets, and one day if the set becomes large enough, you will be re-evaluating those UDFs.
Allow me to quote...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2005 at 9:22 pm
Here's the late night (quiet server) run times for 25K rows...
------------------------------
Function in SELECT
------------------------------
Formula in WHERE
------------------------------
Function in WHERE
------------------------------
==============================
Function in SELECT
--Jeff Moden
Change is inevitable... Change for the better is not.
December 7, 2005 at 7:30 am
Ah... now I see
... it was 200k rows, not 2M rows... too late at night... It does support what we said earlier......
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2005 at 9:56 pm
No fair!
You used a real server with the Enterprise Edition... I used a pc with the Developer's Edition! ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
December 6, 2005 at 7:35 pm
Well, they say one measurement is worth a thousand speculations.... so, I did one. I'll have to eat a little crow on the "clearly they are not slower" thing but...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 5, 2005 at 8:25 pm
Harley,
That's an outstanding idea! Thank you. It's nice to see people treating SQL as a computer language instead of just a repository. I do have a couple of suggestions, though...
1....
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 10:06 pm
Viewing 15 posts - 58,591 through 58,605 (of 59,099 total)