Viewing 15 posts - 58,561 through 58,575 (of 59,067 total)
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
Serqiy, that was my finding, as well. I was being conservative considering the volitile subject.
My thought is that properly written UDF's are much too valuable to simply write off...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 7:59 pm
Outstanding, Sergiy!
I ran the following and the proc that uses the DateOnly function doesn't take any longer than the other...
USE NORTHWIND
GO
SET STATISTICS TIME ON
GO
CREATE PROCEDURE dbo.ProcTest1 AS
SELECT dbo.DateONLY(ShippedDate)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 4, 2005 at 4:21 pm
Viewing 15 posts - 58,561 through 58,575 (of 59,067 total)