Discussion :

[Aquarius]

Salut,

La nouvelle vient de tomber comme un couperet, on nous laisse pas le choix et il va falloir qu'on migre notre base de Oracle 8i vers MS-SQL Server 2000 d'ici fin 2005 ... et évidement je ne connais rien à MS-SQL Server, ni à Transac/SQL (mais j'aurai le temps d'apprendre).

Disposant de tous les scripts de créations, j'imagine que recréer les tables sera assez simple. Je pense que le transfert de contenu devrait aller aussi. Là où je m'inquiète beaucoup plus c'est LE package (plus de 8000 lignes de PL/SQL) et les triggers (plus de 3300 lignes de code).

Cette migration est-elle donc réaliste ou bien puis-je d'ores et déjà annoncer qu'il faudra tout refaire (package et trigger) ?
Y a-t-il une once de compatibilité entre PL/SQL et Transac/SQL ?
Soyons fou, existe-t-il un outil permettant de faciliter cette migration ?
A quels autres pièges dois-je m'attendre lors de cette migration ?

Merci pour tous les conseils que vous pourrez me donner dans ce domaine.

[Fabien Celaia]

Il va y avoir du boulot ! Pour le transfer des tables et objets non-compiles, PowerDesigner peut de faire un reverse et une conversion.

Pour ce qui est du PL-SQL et du T-SQL, ca a un historique tellement different (QUEL/SQL)... Tu vas decouvrir toute les differences de deux base que chaque service marketing annonce comme ANSI-SQL99

Ceci dit, c'est faisable... meme Broadvision l'a fait...

[Pomalaix]

Bonjour

Dans la doc Oracle, il y a un très instructif chapitre qui liste les différences significatives dans une migration entre Oracle et SQL Server.
Oracle Migration Workbench Reference Guide for Microsoft SQL Server and Sybase Adaptive Server Migrations

D'ailleurs si j'ai le courage, j'en ferais bien un résumé en français, car cette mise en parallèle est tout à fait passionnante.

[Fabien Celaia]

Si ca peut t'aider : SQLPorter

[Aquarius]

Merci à vous deux.

Je viens d'aller faire un tour sur le site de SQLPorter et effectivement ils migrent de pratiquement n'importe quel base vers n'importe quelle autre.

Seul bémol, d'après leur doc technique (en date de janvier 2003) SQLPorter ne migre pas encore les procédures stockées, les vues et les triggers. C'est en cours de développement ... et aucune date n'est annoncée.

Je vais aller faire un saut chez Oracle pour voir...

à+

[Fabien Celaia]

Seul bémol, d'après leur doc technique (en date de janvier 2003) SQLPorter ne migre pas encore les procédures stockées, les vues et les triggers. C'est en cours de développement ... et aucune date n'est annoncée.

Alors, c'est de la foutaise !

[Aquarius]

Bien bien bien... d'après ce que j'ai lu, SQL Server ne supporte pas les triggers BEFORE. Vu que plus de la moitié de mes triggers sont des triggers BEFORE, chuis pas dans la mouise...

Dis voir Fadace, tu as une idée du temps qu'ils ont passé chez Broadvision pour effectuer cette migration ?

[Pomalaix]

Bien bien bien... d'après ce que j'ai lu, SQL Server ne supporte pas les triggers BEFORE. Vu que plus de la moitié de mes triggers sont des triggers BEFORE, chuis pas dans la mouise...

Ca ne sera pas la seule différence hein !
Par exemple SQL Server ne supporte pas non plus les déclencheurs de niveau ligne (FOR EACH ROW).

Mais bon, 2 ans de délai, ça vous laisse le temps d'approfondir toutes ces joyeusetés, ou de convaincre votre direction que passer à SQL Server est une connerie !

[ovh]

On t'a justifié le fait de vouloir passer à SQL Server ou bien on t'a imposé ça comme ça sans commentaire ?

[Aquarius]

C'est une décision du groupe mondial. Donc nous (tous les développeurs et les chefs de projets) on n'a ni le choix, ni notre mot à dire. On doit migrer, point à la ligne. Si j'ai bien compris, c'est principalement pour des raisons financières.

Pour compléter le lien fourni par Pomalaix indiquant comment migrer de SQL Server vers Oracle, voici ce que je viens de trouver chez microsoft pour migrer de Oracle vers SQL server: http://www.microsoft.com/technet/tre...art2/c0761.asp

J'espère qu'avec tout ça on va réussir à s'en sortir

[Marc Musette]

en tout cas ce qui est sûr c'est que l'argument financier ne tient pas la route : les frais de migration vont certainement dépasser les frais relatifs à une db Oracle déjà en place.

sur ce bonne chance et bon travail !

[SQLpro]

Au niveau des frais...
MS fait actuellement du dumping et "vend" quasiement gratuitement certains produits pour concurrencer. Les récentes affaires en matières de collectivités locales sur la suite bureautique le montre bien...

MS serait-il donc aux abois et s'acheminerait-on vers un nouvel Eron ??? Affaire intéressante !

En ce qui concerne les triggers BEFORE, c'est pas très compliqué de les détourner en utilisant la logique de ROLLBACK.
De même pour le EACH ROW avec un cursor updatatble...

A mon sens les plus grandes surprises viendrons de là ou l'on ne s'attends pas : collations, compatibilité des types de données et sensibilité à la casse sont les points les plus durs !

A +