We had someone do a similar thing at work and it caused, on the average, of 624 deadlocks a day because they used UPDATE instead of INSERT.  And we only have...

Just to round out the list of possible solutions...

--===== Find number of days in current month

 SELECT DATEPART(dd,DATEADD(mm,DATEDIFF(mm,0,GETDATE())+1,0)-1)

It works by finding the first day...

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...

Thought it might be a little faster based on the fact that it's eliminated the final calculateion from the SET statement.

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...

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...

Wha'cha figure guys?  Faster still?

 UPDATE d_details

    SET UserField1 = STUFF(UserField1, 1, 4, 'efgh')

  WHERE UserField1 LIKE 'abcd%'

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...

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...

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...

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...

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...

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...

I mentioned indexes (rather, the lack of) in my last reply to Scott.

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...