Discussion :

[breiz35]

Nous avons une appli Delphi 4 utilisant des tables Paradox que nous souhaiterions migrer en Delphi 2006 avec une base Firebird 1.5.
Notre appli est utilisée par 20 clients ayant en moyenne une dizaine d'utilisateurs chacun.
- 1 Est ce une galère au niveau développement.
- 2 La migration pour le client est elle compliquée.
- 3 Est ce un bon choix.
Merci pour vos réponses.

[free07]

Je suis en train de migrer une appli utilisant des tables paradox, la conversion des accès à la base est relativement simple surtout que j'avais tout regrouper les accès dans des DataModule, ce qui simplifie la migration, par contre la difficulté réside dans le changement de type de base, c'est à dire que migrer vers FB change la 'philosophie' de gestion de la BD, on passe à une utilisation en mode client serveur et cela change pas mal de choses...
Surtout au niveau de la gestion des transactions.

[breiz35]

Merci pour ta réponse.
Est ce que tu utilisais ReportSmith.
Et pour l'installation en clientèle est ce compliqué.
Merci

[free07]

Non, j'utilise QuickReports mais je vais peut être en profiter pour changer de générateur d'état, je verrais cela lorsque j'aurais finis ma migration.
Je ne l'ai pas encore finit donc pas encore installé en clientèle

[breiz35]

Merci on se tient au courant suivant l'avancement de nos projets.

[free07]

Ok, par contre, je ne vois pas de pbs particulier pour l'installation en clientèle, pour la reprise des données on peut utiliser IBPump ou écrire un outil spécifique si le temps le permet...

[breiz35]

J'avais pensé fournir une base vide avec toutes les tables créées ainsi que les controles que je souhaite associer aux tables et aux champs ainsi que les procédures et les trigers.
Puis effectivement fournir un petit projet qui remplirai les tables car il faut quand meme les charger dans un certaine ordre si on met de l'intégrité référentielle entre les tables.
a+

[killvince]

Bonjour, je me joins a votre sujet car je suis moi meme en plein travail de migration d'une base paradox, utilisant donc le BDE vers une base firebird 1.5, utilisant DBExpress.
Personnellement, pour les types de données, je n'ai pas trop eu de problemes, j'ai commencé par extraire la structure de ma base et à verifier qu'elle s'integrait bien dans une structure firebird.
Maintenant, je me sers de cette nouvelle base pour tenter de faire migrer mes données de ma base paradox vers cette derniere.

Tout semble fonctionner correctement à un point près, l'applyupdates est impossible, je n'ai aucun retour d'erreur, si je vais verifier les données remplies elles sont bien presentes, je fais alors l'enregistrement et plus rien.

A savoir que je ne remplie pas mes tables a partir de requetes, mes des méthodes de dbexpress, en remplissant les valeurs une a une en parcourant la table paradox.

Sauriez vous s'il y a une incompatibilité entre les méthodes dbexpress, et et firebird? En l'occurence, surtout sur l'enregistrement des modifications par les methodes dbexpress

[breiz35]

Bonjour,
Je n'en suis pas encore là mais je pensais à un truc comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
    tbNewPerson.open;
    tbPerson.first;
    while not tbPerson.eof do
     begin
      tbNewPerson.insert;
      for i := 0 to tbPerson.FieldCount - 1 do
        tbNewPerson.FieldValues[tbPerson.Fields[i].FieldName]:=tbPerson.FieldValues[tbPerson.Fields[i].FieldName];
      try
       tbNewPerson.post;
        except on Edbengineerror do tbNewPerson.cancel;
      end;
      tbPerson.Next;
     end;

Autrement est ce que tu as des arguments qui t'on fait choisir FireBird par rapport à MySql par exemple.
Merci

_______________________________
Balises [Code] rajoutées par yobenzen

[killvince]

Le choix ne a été fait au niveau des specificités de firebird, certaines fonctionalités qui nous étaient nécessaires n'etaient pas presentes avec MySql mais c'etait vraiment propre a notre code. Sinon, c'est vrai que j'avais longuement hésité entre les deux.
En même temps, firebird est un code en pleine evolution, notre application l'etant aussi, nous avons pensé que nous aurions peut etre plus de chance de ne pas etre limité avec FB que mysql.
L'autre alternative que nous traitons en parallele est oracle, nous avons la chance de ne pas nécessité de la version payante, au stade ou nous en sommes, la version Express suffit, et la transition Paradox -> oracle a été bien plus evidente au niveau du code.

[michel_ballasse]

Pour te répondre et complétr ce qui a déjà été dit :
1. ça dépend. Si tu as utilisé des champs spéciaux dans Paradox (autoincrément, boolean, Image, graphic, bitmab, blob, et toute la merdasse qui va avec), bon courage, il te faudra écrire un petit soft de duplication de données avec adaptation de type au passge
2. Pour l'application cliente, je en veux pas tedécevoir, mais danbs la majorité des cas il ya quasielment tout à revoir : manipulation des donénes car il faut intégrer la gestion des transactions, interface utilisateur, cynématique et ergonomie car il faut prendren ecomtpe cette gestion de transactions, lisibilité du code et maintenance
3. Interbase/Firebird se justifie si ton appli doit fonctionner en environnement client/serveur. Après c'est un autre débat de savoir si c'est mieux que SQLServer ou Oracle ou Sybase ou Informix ou .....

Pour l'avoir conseillé et réalisé chez plusieurs clients, il faut en moyenne compter entre 1.5 à 2 jour par table de données (juste la réécriture)

[killvince]

En fin de compte j'ai trouvé une solution tres rapide.
Puisque les applyupdates ne marchaient pas, alors que les execsql oui, j'ai créé une procedure de generation de requetes. Cette procedure marche sur les bases oracle et firebird, donc nous avons economisé pas mal de code, et on en a profiter pour creer un convertisseur de base, on lit la base d'origine et d'apres le type et le format, on l'adapte a chaque base et on lui insere les valeurs.

Cependant, on a quand meme préféré reprendre le script des tables à la main pour la structure puisque peu de type avaient à etre modifié, un petit "remplacer tout" et ct bon