Viewing 15 posts - 58,801 through 58,815 (of 59,063 total)
As WZ700 said, I'm assuming that ID is a "no skip" sequential IDENTITY column...
This will "find" everything that meets your criteria all at once in a single run...
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 24, 2005 at 6:38 am
Thought it might be a little faster based on the fact that it's eliminated the final calculateion from the SET statement.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 23, 2005 at 6:55 am
Greg,
Steve is right... ya gotta watch the variable length when converting dates. The "101" date format I used is a shorty for just date and only requires 10 characters (hence...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 23, 2005 at 6:33 am
It may be that your login(s) do not have the correct permissions to use the debugger. Books-on-line doesn't say what the permissions need to be but I'm thinking that you...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 11:15 pm
Wha'cha figure guys? Faster still?
UPDATE d_details
SET UserField1 = STUFF(UserField1, 1, 4, 'efgh')
WHERE UserField1 LIKE 'abcd%'
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 11:08 pm
Ya just gotta love that Microsoft documentation... the most number of parameters passed to a proc that I've ever seen was 120 and that was a C.R.U.D. proc for a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 10:55 pm
Old programmers trick for remembering what code does... add some comments!
That, not-with-standing, I agree with PW... a UDF certainly seems like the thing to do here...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 10:41 pm
We've had similar problems with Views where I work... everybody thought it was the UDF's... turns out that the "big" view had to fully "materialize" for the smaller views to...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 10:34 pm
Greg,
First, yeah, Wayne is absolutely correct about NVARCHAR vs VARCHAR...
PW was correct, as well, about the single quoted dates except that PW didn't take it far enough.... SQL doesn't, for...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 10:19 pm
Using a combination of VARCHAR(8000) as previously mentioned and multiple variables, you can build stored procedures to the max of 250 MB (for "Bytes in source text of a stored...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2005 at 9:47 pm
Or, you could try ParseName and Replace like this... Like NoelD suggested, TinyInt comes into play... The Str and Convert functions are to zero fill the octects.
DECLARE @MyTCPIP...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2005 at 9:27 pm
I mentioned indexes (rather, the lack of) in my last reply to Scott.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2005 at 8:23 pm
Checkout the ParseName function... it was designed to parse octets in addresses and name in 4 part named database objects. Could help you to shorten your function a bit...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2005 at 8:18 pm
You're welcome.... just in case you didn't know... Books-on-Line is free and comes with SQL Server... it's the name of the rather voluminous on-line help that comes with SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2005 at 8:01 pm
Scott,
No offense was meant and I agree except that I've seen the optimizer give the non-Case method the win 2 out of 3 times when testing with and without proper indexes...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2005 at 7:13 pm
Viewing 15 posts - 58,801 through 58,815 (of 59,063 total)