Moving production server to new box

I'm moving my prod server to a new box. Is the plan below
workable ?
I install the new server at the same SP level as the old
server.
I copy the mdf and ldf files to the new location.
I over write the mdf and ldf files for master with the old
servers copy.
I restart the server.
Since the directory structure is different, I assume that
master will come up but other db's will be suspect.
I update sysdatbases to point to the correct path for the
user databases.
I restart the server.
Is this too simplistic 'Please read this article, and do not move or overwrite MDF/LDF files with
the server shut down!:
http://support.microsoft.com/?kbid=224071
"Jack A" <anonymous@.discussions.microsoft.com> wrote in message
news:1411901c41370$84d51b00$a301280a@.phx
.gbl...
> I'm moving my prod server to a new box. Is the plan below
> workable ?
> I install the new server at the same SP level as the old
> server.
> I copy the mdf and ldf files to the new location.
> I over write the mdf and ldf files for master with the old
> servers copy.
> I restart the server.
> Since the directory structure is different, I assume that
> master will come up but other db's will be suspect.
> I update sysdatbases to point to the correct path for the
> user databases.
> I restart the server.
> Is this too simplistic '
>|||A silly question but why not just use the Copy Database Wizard ?
http://msdn.microsoft.com/library/d...>
wiz_0z50.asp
J
-- Jack A wrote: --
I'm moving my prod server to a new box. Is the plan below
workable ?
I install the new server at the same SP level as the old
server.
I copy the mdf and ldf files to the new location.
I over write the mdf and ldf files for master with the old
servers copy.
I restart the server.
Since the directory structure is different, I assume that
master will come up but other db's will be suspect.
I update sysdatbases to point to the correct path for the
user databases.
I restart the server.
Is this too simplistic '|||Can i use this to move from a Sql 7 to Sql 2000. How do I
start the wizard. Cant find it anywhere in the interface.
>--Original Message--
>A silly question but why not just use the Copy Database
Wizard ?
>http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/adminsql/ad_onmigwiz_0z50.asp
>J
> -- Jack A wrote: --
> I'm moving my prod server to a new box. Is the plan
below
> workable ?
> I install the new server at the same SP level as the
old
> server.
> I copy the mdf and ldf files to the new location.
> I over write the mdf and ldf files for master with
the old
> servers copy.
> I restart the server.
> Since the directory structure is different, I assume
that
> master will come up but other db's will be suspect.
> I update sysdatbases to point to the correct path
for the
> user databases.
> I restart the server.
> Is this too simplistic '
>
>.
>|||The problem is if you have different path for the system databases. Move mas
ter and when you then start SQL
Server, it will look for model and tempdb in the *old* path, which might not
exists and SQL Server will not
start if it can't find these databases...
Moving SQL Server Databases
http://www.support.microsoft.com/?id=224071
Moving Databases between Servers
http://www.support.microsoft.com/?id=314546
Using WITH MOVE in a Restore to a New Location with Detach/Attach
http://support.microsoft.com/?id=221465
How To Transfer Logins and Passwords Between SQL Servers
http://www.support.microsoft.com/?id=246133
Mapping Logins & SIDs after a Restore
http://www.support.microsoft.com/?id=298897
Utility to map users to the correct login
http://www.dbmaint.com/SyncSqlLogins.asp
How to Resolve Permission Issues When a Database Is Moved Between SQL Server
s
http://www.support.microsoft.com/?id=240872
User Logon and/or Permission Errors After Restoring Dump
http://www.support.microsoft.com/?id=168001
Disaster Recovery Articles for SQL Server
http://www.support.microsoft.com/?id=307775
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Jack A" <anonymous@.discussions.microsoft.com> wrote in message
news:1411901c41370$84d51b00$a301280a@.phx
.gbl...
> I'm moving my prod server to a new box. Is the plan below
> workable ?
> I install the new server at the same SP level as the old
> server.
> I copy the mdf and ldf files to the new location.
> I over write the mdf and ldf files for master with the old
> servers copy.
> I restart the server.
> Since the directory structure is different, I assume that
> master will come up but other db's will be suspect.
> I update sysdatbases to point to the correct path for the
> user databases.
> I restart the server.
> Is this too simplistic '
>|||HI
SQL 2000 Enterprise Manager: click 'Run a Wizard' button (or tools menu - Wi
zards...). Expand 'Management' and select 'Copy Database Wizard'.
Select a Source Server: Your old SQL 7.0 server. ...
-- Jack A wrote: --
Can i use this to move from a Sql 7 to Sql 2000. How do I
start the wizard. Cant find it anywhere in the interface.
>--Original Message--
>A silly question but why not just use the Copy Database
Wizard ?
url=/library/en-us/adminsql/ad_onmigwiz_0z50.asp
below
> workable ?
old
> server.
> I over write the mdf and ldf files for master with
the old
> servers copy.
> I restart the server.
> Since the directory structure is different, I assume
that
> master will come up but other db's will be suspect.
> I update sysdatbases to point to the correct path
for the
> user databases.
> I restart the server.
>

moving package from dev to live

I moved one of the ssis packages from dev to prod.
Did the same for the configuration file which contains the connectionstring.
Now I would like to run the package in live but the error is:

Description: The configuration file name "S:\Imports\Trades\Environment.dtsConfig" is not valid. Check the configuration file name.

The file does indeed exist and the connectionstring has the correct string.

Any thoughts please?

How are you executing the package? If via 'SQL Agent' then you need to specify the CONFIG file in the command line, i.e. : - DTEXEC /FILE "<<MyFullPackagePath>>" /CONFIGFILE "<<MyFullConfigPath" /CHECKPOINTING OFF

Moving Objects!

What is the best way to move objects from Dev to Prod. I usally use All Tasks/Generate SQL Script and then run this in query analyzer in Prod. However, If I am moving a couple of tables and they have foreign key constraints, that relationship is lost.
Even when moving one of those tables. How to solve this?
Thanks
probably the best way to do this is via Scripts, although you technicaly
could use DTS or something.
I'm not sure what you mean by losing relationships ....?
You have to script the Indexes, Constraints, Etc.
Explain a little better what you mean.
GAJ
|||I just noticed the scripting options which default to NOT script primary keys, foreign keys. So I'll make sure to check those in the future.
Thanks
"Jaxon" wrote:

> probably the best way to do this is via Scripts, although you technicaly
> could use DTS or something.
> I'm not sure what you mean by losing relationships ....?
> You have to script the Indexes, Constraints, Etc.
> Explain a little better what you mean.
>
> GAJ
>
>

Moving Objects!

What is the best way to move objects from Dev to Prod. I usally use All Tas
ks/Generate SQL Script and then run this in query analyzer in Prod. However
, If I am moving a couple of tables and they have foreign key constraints, t
hat relationship is lost.
Even when moving one of those tables. How to solve this?
Thanksprobably the best way to do this is via Scripts, although you technicaly
could use DTS or something.
I'm not sure what you mean by losing relationships ....?
You have to script the Indexes, Constraints, Etc.
Explain a little better what you mean.
GAJ|||I just noticed the scripting options which default to NOT script primary key
s, foreign keys. So I'll make sure to check those in the future.
Thanks
"Jaxon" wrote:

> probably the best way to do this is via Scripts, although you technicaly
> could use DTS or something.
> I'm not sure what you mean by losing relationships ....?
> You have to script the Indexes, Constraints, Etc.
> Explain a little better what you mean.
>
> GAJ
>
>