Nah, I was thinking of something like this to generate the commands to run. If you want, you could even actually run the code instead of just generating it.

DECLARE...

To me it seems fairly easy to match single rows. Maybe you can just output those matches to a table and then consolidate the like ids using that result.

SELECT...

Since you literally can't add enough values here to make a cursor all that bad, you might want to use a cursor just to have better control over the processing...

DECLARE @database_name NVARCHAR(50)

SELECT @database_name=DB_NAME()

WHILE 1 = 1

BEGIN

IF EXISTS(

SELECT 1

FROM msdb.dbo.backupmediafamily

INNER JOIN msdb.dbo.backupset ON...

No, you'd need to use a synonym for each object. But it's easy enough to generate the code to create the synonyms for all tables in the current db.

Similar to the first option above; you may need to adjust for your specific values:

AND ((@JobStatus IN ('O', 'o') AND JobStatus = 1) OR

...

I'd try a combined query, force it to recompile so SQL can ignore the unmatchable condition:

SELECT JobStatus

FROM dbo.JCJM

WHERE

(@JobStatus IN ('O', 'o') AND JobStatus = 1) OR

...

I prefer just:

DECLARE @MyDate DATETIME;

SET @MyDate = '2/28/2009';

SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, @MyDate) - 11, -1);

The basic trigger rewrite is easy enough, but trying to return the value is and will be a very severe issue. Returning data directly from a trigger should never...

It sets the corresponding bits on, regardless of whether they were on before or not.

For example:

SELECT CAST(0 AS int) | 1 | 2 | 4

SELECT CAST(1 AS int) | 1...

AND AppDetails.DateDetailDisposed >= Dateadd(Day, Datediff(Day, 0, Getdate()), 0) - 21

AND AppDetails.DateDetailDisposed < Dateadd(Day, Datediff(Day, 0, Getdate()), 0) - 20 INNER JOIN

After an index is rebuilt, you should...

I'd take a different approach. How about using synonyms to re-direct from the old schema name to the new one? Then you wouldn't have to directly change any...

Can't troubleshoot that query without more details on it.

One specific thing to check, though, is that you have limited SQL's use of RAM via the 'max memory' setting, and not...

It looks like it could be a good, and perhaps overlooked, area for investigation, but I don't fully understand exactly what is being listed/described by the query.