Discussion :

[Raphael1980]

Bonne rencontre,

Dans le cadre d’un projet, je dois migrer les données d’une base de données vers une autre base de données. Les tables sont différentes au niveau des champs et de la structure. Le format des champs sont par contre identique.

Ne sachant pas trop comment m’y prendre, je me tourne vers vous ? Il y a-t-il une méthode à préconiser ? Dans mon ignorance, je pensais parcourir via des PS la DB source et faire des inserts dans la table destination.

J’ai également un champ varbinary pour les passwords et je ne sais pas trop comment il va réagir à cette migration.

D’avance, merci pour vos conseils.

Amicalement,
Raphaël.

PS : On tourne en MS-SQL 2005

[elsuket]

Bonjour,

Est-ce que les deux bases de données sont hébergées par la même instance de SQL Server ?

J’ai également un champ varbinary pour les passwords et je ne sais pas trop comment il va réagir à cette migration.

Est-ce que cette colonne est cryptée ?

@++

[mikedavem]

Il faudra faire une revue de vos tables et des colonnes cibles et sources en jeu.

Vous pouvez soit passer passer par script soit faire un package SSIS également si certaines transformations sont à réaliser (apparemment ce n'est pas votre cas).

Que va t'il se passer cependant pour vos colonnes qui n'existent pas dans vos tables sources ? Ou celles qui auraient disparu ?

@Elsuket :

L'Académie française précise que le mot « cryptage » est à bannir et il ne figure pas dans son dictionnaire même si on peut le trouver dans des dictionnaires usuels. Toutefois, en France, « crypter » est souvent employé, surtout au passif, dans le cadre de la télévision à péage (on « crypte » des chaînes).

Je te taquine hein ... en plus n'étant pas le mieux placé pour ...

++

[Raphael1980]

Bonne rencontre,

Merci pour vos réponses.

Est-ce que les deux bases de données sont hébergées par la même instance de SQL Server ?

Oui tout à fait.

Est-ce que cette colonne est cryptée ?

Effectivement, elle est cryptée via la fonction EncryptByPassPhrase().

Que va t'il se passer cependant pour vos colonnes qui n'existent pas dans vos tables sources ? Ou celles qui auraient disparu ?

Concernant les colonnes qui n’existent pas dans les tables sources, j’aimerais obtenir un null dans les champs de destination. Ce ne sont que des informations complémentaires sur les profils. Aucune clé par exemple.

Par contre, je n’ai jamais utilisé SQL Server Integration Services. Je vais me documenter sur le sujet.

Amicalement,
Raphaël.