Il y a deux parties à cette question.
Tout d'abord, comment copier/déplacer des données avec des champs d'identité ?
Si vous effectuez régulièrement cette opération entre deux ou plusieurs serveurs, vous devez configurer leurs graines d'identité pour qu'elles soient différentes. Par exemple, si deux serveurs partagent une table contenant un petit nombre d'enregistrements, vous pouvez configurer l'un d'eux avec une graine d'identité de 1, et l'autre avec une graine d'identité de 1 000 000. Un serveur commencera son champ d'identité à 1 et augmentera, et l'autre à la valeur la plus élevée. Bien sûr, vous devez toujours garder un œil sur ce point pour vous assurer que vous ne vous retrouvez pas avec des enregistrements qui se chevauchent.
Ensuite, lorsque vous voulez copier des données d'un serveur à un autre, vous préfixez vos insertions avec la commande SET IDENTITY_INSERT comme indiqué ici :
http://msdn.microsoft.com/en-us/library/ms188059.aspx
Vous pouvez ensuite désactiver temporairement le champ d'identité afin de pouvoir pomper des données d'un serveur à l'autre.
Deuxièmement, comment copier/déplacer des données en général ?
Il y a plusieurs façons de le faire :
- Réplication SQL Server - peut synchroniser automatiquement les données entre plusieurs serveurs. Elle est intégrée au produit et est flexible, mais sa mise en place et sa gestion sont difficiles. Il ne permet pas de synchroniser les environnements de développement et de test comme vous le souhaitez.
- Scripting avec SQL Server Management Studio - fonctionne, mais manque de flexibilité, et c'est aussi un casse-tête manuel.
- Comparaisons de données/schémas avec des produits tiers - outils tels que Toad for SQL Server compare les schémas et les données entre deux serveurs et les synchronise. (Avertissement : je travaille pour Quest, les créateurs de Toad).
Si vous déplacez des données entre le serveur de production et le serveur de test, restaurez les données de production sur votre serveur de test sous un autre nom de base de données, puis effectuez vos synchronisations de base de données à cet endroit. Ce sera plus rapide, cela n'aura pas d'impact sur votre boîte de production, et si vous faites quelque chose de mal (comme synchroniser les données dans le mauvais sens), cela ne détruira pas la production.