sp_msforeachtable is undocumented by Microsoft, but one of the best procs out there....as is it's companion sp_msforeachdb

The failure to execute of your full backup should not have affected your logshipping in any way. Are you recreating logshipping on a nightly basis?

EMC SAN huh?

SP_MSFOREACHTABLE "select '?', count(column_name) from ?"

You can prevent this by using the openquery functionality...

First you tell it to insert, then the openquery, actually provide a query (one that will return a single row is best),...

You should execute an alter table alter column statement through query analyser rather than go through enterprise manager. When you run an alter table through EM it creates a temporary table...

Is this a server maintained by yourself? Or do you have a dba for general SQL administration?

If you are tasked with creating the login you would need to be at...

You're missing the quotes around the first BALLOONS, and need to change the second column name from COLUMN_A, also make sure to set the quoted identifier off..should be

SET QUOTED_IDENTIFIER OFF

update...

If you look up CAST AND CONVERT in BOL they have a list of the possible date formats. The date format that you run defines the order of the entries...

If your strings are always 6 chars and the same format you could use

declare @date varchar(10), @day char(2), @mnth char(2), @yr char(2)

set @date = '101004'

select @mnth = substring(@date, 1, 2)

select...

What you do is search on the wildcard string and replace the literal string...thus...

SET QUOTED_IDENTIFIER OFF

 update TABLE set COLUMN_A =REPLACE(COLUMN_A,"BALLOONS","BALLOON")

   where COLUMN_A like "%BALLOONS%"

Run it in a transaction and check the results...

There is no chance for collision between the filenames as they are prefixed with the database name.

You don't have to use a seperate share for each, I use a single...

exec master..xp_cmdshell 'del c:\whateverthefilenameis'

xp_cmdshell is locked down by default (for good reason), be extremely wary doing this, all kinds of bad things can happen

As you are not clustering I really don't see the need for a SAN. I'd stick with external arrays, you'd save yourself more than 50%, and then you could persuade...

Are your SQL server clustered and all production?