Viewing 15 posts - 57,061 through 57,075 (of 59,101 total)
Shoot... didn't mean to make it sound like I took it any other way... guess I need to use more smiley faces ![]()

--Jeff Moden
Change is inevitable... Change for the better is not.
January 21, 2007 at 9:06 am
Serqiy and Barry,
Heh... I finally drank enough coffee and now I get it... and I agree. Serqiy is absolutely correct.
Actually, my fault... All I saw was "the latest 50 rows"...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 21, 2007 at 8:56 am
Heh... thanks for the feedback, Remi.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 9:57 pm
Thanks for the feedback, folks. Glad it helped.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 9:48 pm
In the presence of an appropriate index, DClark's method and the following method both work at about the same speed and both do the same thing functionally...
DELETE FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 9:15 pm
Don't need it... N is the clustered Primary Key. Yeah, I know what you're going to say...
Anyway, the length in the substrings is hardcoded... surely you're not suggesting that I...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 6:32 pm
If you have a Tally table, here's a possible solution, as well...
CREATE FUNCTION dbo.StripNonDigit(@Input VARCHAR(8000))
RETURNS VARCHAR(8000)
AS
BEGIN
DECLARE @Result VARCHAR(8000)
SELECT @Result = ISNULL(@Result,'')
...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 11:39 am
Yep... I agree with Serquiy... if it's for an automatic dialer (or ever could be) or for humans to actually know whether it might be an international call just by...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 11:14 am
True enough
, Serqiy, but if you want to name variables for flexibility, it is an error to name them after the actual...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 11:11 am
I'm with PW... I normally use "Derived Tables", as well. And, I normally don't like correlated subqueries because they can be difficult to troubleshoot. But their use seems appropriate just...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 10:52 am
Got a code example for this particular "keep last 50" problem so we can see what you're talking about? I think you're talking about pre-assigning constants as variables which also...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 8:54 am
Nicely done... although I do hope no one actually tries to pass a billion characters worth of parameters ![]()
By the way... you hardcoded the 2's...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 1:12 am
Some of the solutions on the link seem, well... a bit bulky... I don't remember where I got it from but this works and it's nasty fast...
USE NorthWind
GO
CREATE...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 12:30 am
No "error"... Think of it as an "interation step" "that I hope will never be changed in my lifetime"... ![]()
...unless you'd rather see...
WHERE RowNum <=...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 20, 2007 at 12:06 am
This is SO much easier if you have a RowNum column....
SET NOCOUNT ON
DECLARE @MyTable TABLE
(
RowNum INT IDENTITY(1,1) PRIMARY KEY,
ItemName VARCHAR(6),
ItemNo INT,
ItemValue NUMERIC(20, 2)
)
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
Change is inevitable... Change for the better is not.
January 19, 2007 at 11:52 pm
Viewing 15 posts - 57,061 through 57,075 (of 59,101 total)