Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Deployment from Test to Production Environment
Message
Information générale
Forum:
Microsoft SQL Server
Catégorie:
Installation
Divers
Thread ID:
00362601
Message ID:
00362791
Vues:
16
Hi Mike (and all),

Here is a reply a received from Drew Georgopoulos:

"Yes, there are a couple of techniques;
sp_detach and sp_attachdb are the easiest ways to disconnect and move the
database.
Alternatively, you can restore a dump to the new server and it will create
the database and logs for you (2mb big I think if you don't specify
anything), the problem with this method is that the login mapping to users
will be lost, because the new server doesn't know about the old users. The
solution is to bcp the sysusers info out, and then bcp it back to the target
server so you can re-create the mapping between users and logins at the new
server.
Finally, you can do the whole operation by scripts, where the source server
scripts out its database objects, and you bcp the data out into text files,
then use the scripts to re-create the database on the target server
(starting with sp_revdatabase) and bcp the data back in. This is the most
work, but also gives you the most control over the operation."



>>What I'm mainly concerned with here is moving SQL files between 2 machines which are not necessarily linked with one another...I received the following reply from Yair Alan Griver on this question:
>>
>>"Basically, you can detach and reattach, or create a backup and restore on
>>the other machine. Until SQL7, you couldn't do the first, so I tend to stick
>>to the second out of habit..."
>
>When using backup/restore to move databases, the only thing to watch out for is that both servers must have the same character set and sort order.
>
>-Mike
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform