Viewing 15 posts - 58,801 through 58,815 (of 59,067 total)
If you're not trying to do this in a script and just see or edit what's in the proc, open Query Analyzer, press [f8] to view the object tree, find the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2005 at 5:48 pm
Yup, once I identified the problem and fixed it, we went back to zero deadlocks. Just wanted everyone to know that this type of thing, if done incorrectly, can really...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2005 at 6:07 am
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2005 at 2:42 pm
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...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2005 at 2:19 pm
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
Viewing 15 posts - 58,801 through 58,815 (of 59,067 total)