Comparer données : base firebird et sql server

**mercure07** · 21/04/2008, 09h57

Salut à tous, j'ai écrit un programme en C++/Qt qui à partir d'une base de données SqlServer crée une base firebird 1.5 dialecte 1 et importe les données contenues dans la base SqlServer vers la base Firebird.
Et vu que les données sont très critiques et sensibles, il doit y avoir une exactitude totale. Pour cela, je désire valider l'exactitude des données entre les 2 bases, mais le problème c'est que je n'ai pas trouvé une solution adéquate pour ce problème.
Es ce que quelqu'un a une idée et peut m'aider.
Meilleurs salutations, Mourad.

**makowski** · 21/04/2008, 10h38

pourquoi 1.5 et surtout pourquoi dialect 1
c'est vraiment un mauvais choix qui ne te ferra que des misères dans le futur

**VLDG** · 21/04/2008, 21h14

Envoyé par makowski

dialect 1
c'est vraiment un mauvais choix qui ne te ferra que des misères dans le futur

Moi, j'utilise toujours le dialecte 1 car je crois qu'a l'époque il n'y avait que ça !
Je me suis jamais vraiment posé la question d'une conversion. C'est quoi le problème et la méthode pour migrer ?

**makowski** · 21/04/2008, 22h36

rester en dialect 1 c'est perdre une bone partie des fonctionnalités de firebird
ne pas avoir de champs date, time, bigint et dans les futures versions de Firebird, il sera certainement abandonné
Il ne faut pas oublier que le dialect 1 est supporté normalement juste pour compatibilité avec des bases Interbase 5 !

La meilleure méthode est de créer une base en dialect 3 puis de transferer les données

**VLDG** · 22/04/2008, 23h24

j'avais commencé avec Interbase 5.6 (je crois) au départ.

Pour la migration, il n'y a pas d'autres méthodes car ça me semble compliqué à faire chez des clients !

**makowski** · 23/04/2008, 08h57

pas forcement compliqué, en tout cas moins que le changement de version de l'OS d'un serveur

, peut être un peu long, tout dépend de la taille
de la base
Pierre Y a écrit un "datapump" avec les UIB très efficace

**SergioMaster** · 23/04/2008, 11h48

le problème du passage en DIALECT 3 c'est surtout si des champs sont nommés comme les nouveaux mots clés

exemple : CASE , TYPE ce que hélas j'avais utilisé dans une base IB 5.6
- il faut les renommer
- et revoir alors tout les programmes

**makowski** · 23/04/2008, 22h41

Envoyé par SergioMaster

exemple : CASE , TYPE ce que hélas j'avais utilisé dans une base IB 5.6
- il faut les renommer
- et revoir alors tout les programmes

ou les mettre entre guillemets

**VLDG** · 23/04/2008, 23h13

je n'ai pas de nom de champ aussi simple

mes bases sont petites (environ 200 Mo)

je suis dans tous les cas obligé de faire un datapump ?

**makowski** · 24/04/2008, 17h49

en gros oui
c'est le seul moyen de réécrire correctement les données
Clony&Pumpy est là :
http://uib.svn.sourceforge.net/viewv...CloneDatabase/

**SergioMaster** · 25/04/2008, 08h11

Envoyé par makowski

ou les mettre entre guillemets

+1
mais cela n'empêche il faudra revoir les programmes

ne serait-ce que pour y mettre ces fameuses ""

**makowski** · 25/04/2008, 08h24

oui, mais CASE ou TYPE déjà à l'époque d'Interbase 5.6 étaient des mots réservés dans la norme SQL

**SergioMaster** · 25/04/2008, 10h14

Envoyé par makowski

mais CASE ou TYPE déjà à l'époque d'Interbase 5.6 étaient des mots réservés dans la norme SQL

sur ? lorsque j'ai construit l'architecture de la base j'ai du raté quelque chose alors

il était tellement evident et plus lisible d'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE ARTICLES(
NOM CHAR(15),
TYPE CHAR(1),
...)
 
que
 
CREATE TABLE ARTICLES(
NOM CHAR(15),
TYPE_ARTICLE CHAR(1),
...)

que ça m'a echappé et IB n'a rien fait pour m'en empêcher le vilain

**makowski** · 25/04/2008, 11h03

Interbase 5.6 c'est quand ? 2005 ?
dans sql92 CASE était réservé, TYPE pas reservé dans la norme, mais réservé déjà dans d'autres sgbd
cf http://sqlpro.developpez.com/cours/motsreserves/

quand à Interbase 5.6, ben c'est Interbase, pas Firebird

**SergioMaster** · 29/04/2008, 09h13

un autre problème de passage de Dialect 1 à 3 au niveau des programmes (DELPHI) les champs calculés (COMPUTED BY) ne sont plus du même type

du coup je suis obligé de temporiser le passage jusqu'à avoir revu toute mon appliusineagaz (elle fait presque le café, sur 10ans pas étonnant) pour pouvoir profiter pleinement du Dialect 3

à moins qu'il y ait une astuce