Restore to a new database failed

Hello, I have a database backup taken from SQL Server 2005. I originally had placed the backup into a file in My Documents, but when I went to locate the backup file there (C:/Documents and Settings...), the folders would not expand. So I moved the backup to the C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup directory and was able to select the file there. When I try to restore this file into SQL Server 2005 Express using the Management Studio, I get the following error message:

Restore failed for Server 'DELL670DESKTOP\SQLEXPRESS'. (Microsoft.SqlServer.Express.Smo)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.3042.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Restore+Server&LinkId=20476

Program Location:

at Microsoft.SqlServer.Management.Smo.Restore.SqlRestore(Server srv)
at Microsoft.SqlServer.Management.SqlManagerUI.SqlRestoreDatabaseOptions.RunRestore()

===================================

System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\sequoia.mdf'. (Microsoft.SqlServer.Express.Smo)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.3042.00&LinkId=20476

Can you please help me figure out what I am doing wrong?

Thanks so much, LC

Make sure the database file does already exist. You will need to choose a different name for the database.

|||I did select a new name for the database. What do you mean "make sure the database file does already exist"? Or did you mean "doesn't"?

|||

In this section of the error message:

===================================

System.Data.SqlClient.SqlError: The operating system returned the error '5(Access is denied.)' while attempting 'RestoreContainer::ValidateTargetForCreation' on 'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\sequoia.mdf'. (Microsoft.SqlServer.Express.Smo)

you can see that the restore is attempting to put the file in the MSSQL folder -NOT the BackUp folder.

You may wish to explore using the 'WITH MOVE ' parameter for the RESTORE command in order to RESTORE the backup to a different location.

Refer to Books Online, Topic: RESTORE

|||Thank you so much - that did the trick!

Restore sql 2000 database .bak file to sql 2005

I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
is "
Restore failed for Server" - The backup set holds a backup of a
database other than the existing 'db name here ' database.
(Microsoft.SqlServer.Smo)
Pleawse help
Add WITH REPLACE to your RESTORE DATABASE statement if you want to restore
from a backup file of a different database.
Linchi
"CW" <wallacec@.gmail.com> wrote in message
news:1139442397.257269.102990@.g44g2000cwa.googlegr oups.com...
>I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
> is "
> Restore failed for Server" - The backup set holds a backup of a
> database other than the existing 'db name here ' database.
> (Microsoft.SqlServer.Smo)
> Pleawse help
>
|||RESTORE DATABASE DB_NAME_TO_BE_RESTORED
FROM DISK = 'F:\backupfilename.bak'
WITH MOVE 'Logical_Name_Data' TO 'F:\MSSQL\DATA\Physical_Name_Data.mdf',
MOVE 'Logical_Data_Log' TO 'E:\MSSQL\LOG\Physical_Name_Log.ldf',
STATS = 1, REPLACE
GO
Thanks,
Sree
"Linchi Shea" wrote:

> Add WITH REPLACE to your RESTORE DATABASE statement if you want to restore
> from a backup file of a different database.
> Linchi
> "CW" <wallacec@.gmail.com> wrote in message
> news:1139442397.257269.102990@.g44g2000cwa.googlegr oups.com...
>
>

Restore sql 2000 database .bak file to sql 2005

I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
is "
Restore failed for Server" - The backup set holds a backup of a
database other than the existing 'db name here ' database.
(Microsoft.SqlServer.Smo)
Pleawse helpAdd WITH REPLACE to your RESTORE DATABASE statement if you want to restore
from a backup file of a different database.
Linchi
"CW" <wallacec@.gmail.com> wrote in message
news:1139442397.257269.102990@.g44g2000cwa.googlegroups.com...
>I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
> is "
> Restore failed for Server" - The backup set holds a backup of a
> database other than the existing 'db name here ' database.
> (Microsoft.SqlServer.Smo)
> Pleawse help
>|||RESTORE DATABASE DB_NAME_TO_BE_RESTORED
FROM DISK = 'F:\backupfilename.bak'
WITH MOVE 'Logical_Name_Data' TO 'F:\MSSQL\DATA\Physical_Name_Data.mdf',
MOVE 'Logical_Data_Log' TO 'E:\MSSQL\LOG\Physical_Name_Log.ldf',
STATS = 1, REPLACE
GO
Thanks,
Sree
"Linchi Shea" wrote:
> Add WITH REPLACE to your RESTORE DATABASE statement if you want to restore
> from a backup file of a different database.
> Linchi
> "CW" <wallacec@.gmail.com> wrote in message
> news:1139442397.257269.102990@.g44g2000cwa.googlegroups.com...
> >I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
> > is "
> > Restore failed for Server" - The backup set holds a backup of a
> > database other than the existing 'db name here ' database.
> > (Microsoft.SqlServer.Smo)
> > Pleawse help
> >
>
>sql

Restore sql 2000 database .bak file to sql 2005

I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
is "
Restore failed for Server" - The backup set holds a backup of a
database other than the existing 'db name here ' database.
(Microsoft.SqlServer.Smo)
Pleawse helpAdd WITH REPLACE to your RESTORE DATABASE statement if you want to restore
from a backup file of a different database.
Linchi
"CW" <wallacec@.gmail.com> wrote in message
news:1139442397.257269.102990@.g44g2000cwa.googlegroups.com...
>I am trying to restore a sql 2000 .bak file to a sql 2005. Error I get
> is "
> Restore failed for Server" - The backup set holds a backup of a
> database other than the existing 'db name here ' database.
> (Microsoft.SqlServer.Smo)
> Pleawse help
>|||RESTORE DATABASE DB_NAME_TO_BE_RESTORED
FROM DISK = 'F:\backupfilename.bak'
WITH MOVE 'Logical_Name_Data' TO 'F:\MSSQL\DATA\Physical_Name_Data.mdf',
MOVE 'Logical_Data_Log' TO 'E:\MSSQL\LOG\Physical_Name_Log.ldf',
STATS = 1, REPLACE
GO
Thanks,
Sree
"Linchi Shea" wrote:

> Add WITH REPLACE to your RESTORE DATABASE statement if you want to restore
> from a backup file of a different database.
> Linchi
> "CW" <wallacec@.gmail.com> wrote in message
> news:1139442397.257269.102990@.g44g2000cwa.googlegroups.com...
>
>

restore MSDB or transfer jobs?

I restored MSDB onto a new box and my jobs won't run now:
Unable to connect to SQL Server '(local)'. The step failed.
Am I better off to use the Transfer Jobs Task in DTS or is there a simple
answer to this? If so, what about moving the DTS Packages?
SQL2K SP3
TIA, ChrisR
I would scrip them out an apply on new server. But you might be able
to fix them on the new server
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('ServerName') as
nvarchar(50))
update msdb..sysjobs
set originating_server = @.NewServerName
GO
checkpoint
GO
|||The query converts the @.NewServerName to nothing:
Server: Msg 515, Level 16, State 2, Line 3
Cannot insert the value NULL into column 'originating_server', table
'msdb.dbo.sysjobs'; column does not allow nulls. UPDATE fails.
The statement has been terminated.
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('MyBox') as nvarchar(50))
print @.NewServerName
However, I did do an old fashioned:
Update SysJobs
set originating_server = 'MyBox'
but still I have the same problem.
If I did the script method, what would I do with my DTS Packages? Just save
to the new box? Would I be missing anything then from NOT restoring MSDB?
What do most of you do in this scenario?
"bert" <bertcord@.gmail.com> wrote in message
news:1106868585.875164.102430@.z14g2000cwz.googlegr oups.com...
> I would scrip them out an apply on new server. But you might be able
> to fix them on the new server
> declare @.NewServerName varchar(50)
> select @.NewServerName = cast(serverproperty ('ServerName') as
> nvarchar(50))
> update msdb..sysjobs
> set originating_server = @.NewServerName
> GO
> checkpoint
> GO
>
|||select serverproperty ('ServerName') returns null?
Sorry cant help you with the DTS jobs... I stay away from DTS.
did you stop and restart SQL
Bert
|||Have a look here: http://www.sqldts.com/default.aspx?204
Andrew J. Kelly SQL MVP
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||Not an option. Thanks Bert.
"bert" <bertcord@.gmail.com> wrote in message
news:1106878056.175663.124700@.z14g2000cwz.googlegr oups.com...
> select serverproperty ('ServerName') returns null?
> Sorry cant help you with the DTS jobs... I stay away from DTS.
> did you stop and restart SQL
> Bert
>
|||Thanks Andrew.
The "Save as" option suits me just fine. But assuming I do that in place of
Restoring MSDB, what about the jobs? Both the jobs to run these DTS Packages
and those that don't. I know the other options are to script them or to use
DTS to transfer them. Is anyone aware of the pros/ cons for either one? If I
do either of these methods, will I be missing something vital from NOT
Restoring MSDB? I don't think so based on past experience, but its been a
while.
TIA, ChrisR
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
> I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||I prefer to script the jobs myself but I don't know of any thing that says
that is better or worse than moving MSDB per say. Even the KB that talks
about moving DB's suggests moving jobs via scripting.
http://www.support.microsoft.com/?id=314546
Andrew J. Kelly SQL MVP
"ChrisR" <ChrisR@.noEmail.com> wrote in message
news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
> Thanks Andrew.
> The "Save as" option suits me just fine. But assuming I do that in place
> of
> Restoring MSDB, what about the jobs? Both the jobs to run these DTS
> Packages
> and those that don't. I know the other options are to script them or to
> use
> DTS to transfer them. Is anyone aware of the pros/ cons for either one? If
> I
> do either of these methods, will I be missing something vital from NOT
> Restoring MSDB? I don't think so based on past experience, but its been a
> while.
> TIA, ChrisR
>
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>
|||Thanks again Andrew. I think Im going to change my strategy on this whole
thing. It seems like to "Save as" for the DTS Packages and Script the Jobs/
Operators/ and Alerts I could get everything that I would from Restoring
MSDB minus a few headaches.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:#AVGIwUBFHA.3924@.TK2MSFTNGP10.phx.gbl...[vbcol=seagreen]
> I prefer to script the jobs myself but I don't know of any thing that says
> that is better or worse than moving MSDB per say. Even the KB that talks
> about moving DB's suggests moving jobs via scripting.
> http://www.support.microsoft.com/?id=314546
>
> --
> Andrew J. Kelly SQL MVP
>
> "ChrisR" <ChrisR@.noEmail.com> wrote in message
> news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
If[vbcol=seagreen]
a[vbcol=seagreen]
simple
>

restore MSDB or transfer jobs?

I restored MSDB onto a new box and my jobs won't run now:
Unable to connect to SQL Server '(local)'. The step failed.
Am I better off to use the Transfer Jobs Task in DTS or is there a simple
answer to this? If so, what about moving the DTS Packages?
--
SQL2K SP3
TIA, ChrisRI would scrip them out an apply on new server. But you might be able
to fix them on the new server
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('ServerName') as
nvarchar(50))
update msdb..sysjobs
set originating_server = @.NewServerName
GO
checkpoint
GO|||The query converts the @.NewServerName to nothing:
Server: Msg 515, Level 16, State 2, Line 3
Cannot insert the value NULL into column 'originating_server', table
'msdb.dbo.sysjobs'; column does not allow nulls. UPDATE fails.
The statement has been terminated.
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('MyBox') as nvarchar(50))
print @.NewServerName
However, I did do an old fashioned:
Update SysJobs
set originating_server = 'MyBox'
but still I have the same problem.
If I did the script method, what would I do with my DTS Packages? Just save
to the new box? Would I be missing anything then from NOT restoring MSDB?
What do most of you do in this scenario?
"bert" <bertcord@.gmail.com> wrote in message
news:1106868585.875164.102430@.z14g2000cwz.googlegroups.com...
> I would scrip them out an apply on new server. But you might be able
> to fix them on the new server
> declare @.NewServerName varchar(50)
> select @.NewServerName = cast(serverproperty ('ServerName') as
> nvarchar(50))
> update msdb..sysjobs
> set originating_server = @.NewServerName
> GO
> checkpoint
> GO
>|||select serverproperty ('ServerName') returns null?
Sorry cant help you with the DTS jobs... I stay away from DTS.
did you stop and restart SQL
Bert|||Have a look here: http://www.sqldts.com/default.aspx?204
--
Andrew J. Kelly SQL MVP
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Thanks Andrew.
The "Save as" option suits me just fine. But assuming I do that in place of
Restoring MSDB, what about the jobs? Both the jobs to run these DTS Packages
and those that don't. I know the other options are to script them or to use
DTS to transfer them. Is anyone aware of the pros/ cons for either one? If I
do either of these methods, will I be missing something vital from NOT
Restoring MSDB? I don't think so based on past experience, but its been a
while.
TIA, ChrisR
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
> I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Not an option. Thanks Bert.
"bert" <bertcord@.gmail.com> wrote in message
news:1106878056.175663.124700@.z14g2000cwz.googlegroups.com...
> select serverproperty ('ServerName') returns null?
> Sorry cant help you with the DTS jobs... I stay away from DTS.
> did you stop and restart SQL
> Bert
>|||I prefer to script the jobs myself but I don't know of any thing that says
that is better or worse than moving MSDB per say. Even the KB that talks
about moving DB's suggests moving jobs via scripting.
http://www.support.microsoft.com/?id=314546
Andrew J. Kelly SQL MVP
"ChrisR" <ChrisR@.noEmail.com> wrote in message
news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
> Thanks Andrew.
> The "Save as" option suits me just fine. But assuming I do that in place
> of
> Restoring MSDB, what about the jobs? Both the jobs to run these DTS
> Packages
> and those that don't. I know the other options are to script them or to
> use
> DTS to transfer them. Is anyone aware of the pros/ cons for either one? If
> I
> do either of these methods, will I be missing something vital from NOT
> Restoring MSDB? I don't think so based on past experience, but its been a
> while.
> TIA, ChrisR
>
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>> I restored MSDB onto a new box and my jobs won't run now:
>> Unable to connect to SQL Server '(local)'. The step failed.
>> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
>> answer to this? If so, what about moving the DTS Packages?
>> --
>> SQL2K SP3
>> TIA, ChrisR
>>
>|||Thanks again Andrew. I think Im going to change my strategy on this whole
thing. It seems like to "Save as" for the DTS Packages and Script the Jobs/
Operators/ and Alerts I could get everything that I would from Restoring
MSDB minus a few headaches.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:#AVGIwUBFHA.3924@.TK2MSFTNGP10.phx.gbl...
> I prefer to script the jobs myself but I don't know of any thing that says
> that is better or worse than moving MSDB per say. Even the KB that talks
> about moving DB's suggests moving jobs via scripting.
> http://www.support.microsoft.com/?id=314546
>
> --
> Andrew J. Kelly SQL MVP
>
> "ChrisR" <ChrisR@.noEmail.com> wrote in message
> news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
> > Thanks Andrew.
> >
> > The "Save as" option suits me just fine. But assuming I do that in place
> > of
> > Restoring MSDB, what about the jobs? Both the jobs to run these DTS
> > Packages
> > and those that don't. I know the other options are to script them or to
> > use
> > DTS to transfer them. Is anyone aware of the pros/ cons for either one?
If
> > I
> > do either of these methods, will I be missing something vital from NOT
> > Restoring MSDB? I don't think so based on past experience, but its been
a
> > while.
> >
> > TIA, ChrisR
> >
> >
> >
> > "ChrisR" <bla@.noemail.com> wrote in message
> > news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
> >> I restored MSDB onto a new box and my jobs won't run now:
> >>
> >> Unable to connect to SQL Server '(local)'. The step failed.
> >>
> >> Am I better off to use the Transfer Jobs Task in DTS or is there a
simple
> >> answer to this? If so, what about moving the DTS Packages?
> >>
> >> --
> >> SQL2K SP3
> >>
> >> TIA, ChrisR
> >>
> >>
> >
> >
>

restore MSDB or transfer jobs?

I restored MSDB onto a new box and my jobs won't run now:
Unable to connect to SQL Server '(local)'. The step failed.
Am I better off to use the Transfer Jobs Task in DTS or is there a simple
answer to this? If so, what about moving the DTS Packages?
SQL2K SP3
TIA, ChrisRI would scrip them out an apply on new server. But you might be able
to fix them on the new server
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('ServerName') as
nvarchar(50))
update msdb..sysjobs
set originating_server = @.NewServerName
GO
checkpoint
GO|||The query converts the @.NewServerName to nothing:
Server: Msg 515, Level 16, State 2, Line 3
Cannot insert the value NULL into column 'originating_server', table
'msdb.dbo.sysjobs'; column does not allow nulls. UPDATE fails.
The statement has been terminated.
declare @.NewServerName varchar(50)
select @.NewServerName = cast(serverproperty ('MyBox') as nvarchar(50))
print @.NewServerName
However, I did do an old fashioned:
Update SysJobs
set originating_server = 'MyBox'
but still I have the same problem.
If I did the script method, what would I do with my DTS Packages? Just save
to the new box? Would I be missing anything then from NOT restoring MSDB?
What do most of you do in this scenario?
"bert" <bertcord@.gmail.com> wrote in message
news:1106868585.875164.102430@.z14g2000cwz.googlegroups.com...
> I would scrip them out an apply on new server. But you might be able
> to fix them on the new server
> declare @.NewServerName varchar(50)
> select @.NewServerName = cast(serverproperty ('ServerName') as
> nvarchar(50))
> update msdb..sysjobs
> set originating_server = @.NewServerName
> GO
> checkpoint
> GO
>|||select serverproperty ('ServerName') returns null?
Sorry cant help you with the DTS jobs... I stay away from DTS.
did you stop and restart SQL
Bert|||Have a look here: http://www.sqldts.com/default.aspx?204
Andrew J. Kelly SQL MVP
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Not an option. Thanks Bert.
"bert" <bertcord@.gmail.com> wrote in message
news:1106878056.175663.124700@.z14g2000cwz.googlegroups.com...
> select serverproperty ('ServerName') returns null?
> Sorry cant help you with the DTS jobs... I stay away from DTS.
> did you stop and restart SQL
> Bert
>|||Thanks Andrew.
The "Save as" option suits me just fine. But assuming I do that in place of
Restoring MSDB, what about the jobs? Both the jobs to run these DTS Packages
and those that don't. I know the other options are to script them or to use
DTS to transfer them. Is anyone aware of the pros/ cons for either one? If I
do either of these methods, will I be missing something vital from NOT
Restoring MSDB? I don't think so based on past experience, but its been a
while.
TIA, ChrisR
"ChrisR" <bla@.noemail.com> wrote in message
news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
> I restored MSDB onto a new box and my jobs won't run now:
> Unable to connect to SQL Server '(local)'. The step failed.
> Am I better off to use the Transfer Jobs Task in DTS or is there a simple
> answer to this? If so, what about moving the DTS Packages?
> --
> SQL2K SP3
> TIA, ChrisR
>|||I prefer to script the jobs myself but I don't know of any thing that says
that is better or worse than moving MSDB per say. Even the KB that talks
about moving DB's suggests moving jobs via scripting.
http://www.support.microsoft.com/?id=314546
Andrew J. Kelly SQL MVP
"ChrisR" <ChrisR@.noEmail.com> wrote in message
news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
> Thanks Andrew.
> The "Save as" option suits me just fine. But assuming I do that in place
> of
> Restoring MSDB, what about the jobs? Both the jobs to run these DTS
> Packages
> and those that don't. I know the other options are to script them or to
> use
> DTS to transfer them. Is anyone aware of the pros/ cons for either one? If
> I
> do either of these methods, will I be missing something vital from NOT
> Restoring MSDB? I don't think so based on past experience, but its been a
> while.
> TIA, ChrisR
>
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ub2Z2MMBFHA.2392@.TK2MSFTNGP14.phx.gbl...
>|||Thanks again Andrew. I think Im going to change my strategy on this whole
thing. It seems like to "Save as" for the DTS Packages and Script the Jobs/
Operators/ and Alerts I could get everything that I would from Restoring
MSDB minus a few headaches.
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:#AVGIwUBFHA.3924@.TK2MSFTNGP10.phx.gbl...
> I prefer to script the jobs myself but I don't know of any thing that says
> that is better or worse than moving MSDB per say. Even the KB that talks
> about moving DB's suggests moving jobs via scripting.
> http://www.support.microsoft.com/?id=314546
>
> --
> Andrew J. Kelly SQL MVP
>
> "ChrisR" <ChrisR@.noEmail.com> wrote in message
> news:uQAGA5PBFHA.3524@.TK2MSFTNGP15.phx.gbl...
If[vbcol=seagreen]
a[vbcol=seagreen]
simple[vbcol=seagreen]
>

Restore MASTER

Hi there,
My RAID data drive failed, and I need to restore the MASTER DB. When I
put the server into single user mode (sqlservr -m ) and launch
Enterprise Manager, or Query Analyzer, I can't log into to perform the
restore. It informs me that the server is running in single user mode
(which it is) and that only one admin can be connected.. I have even
attempt to connect using a named SQL user.
How can I overcome this problem?Make sure that the SQLServerAgent service is not running.
"Rowan Prior" wrote:
> Hi there,
> My RAID data drive failed, and I need to restore the MASTER DB. When I
> put the server into single user mode (sqlservr -m ) and launch
> Enterprise Manager, or Query Analyzer, I can't log into to perform the
> restore. It informs me that the server is running in single user mode
> (which it is) and that only one admin can be connected.. I have even
> attempt to connect using a named SQL user.
> How can I overcome this problem?
>