Migration or not migration ?

Version imprimable

20/05/2009, 21h59
Sitas

Migration or not migration ?

Salut à tous,

Je travaille sur une application développée sous D7/WinXP/dBase(IV). Le problème est qu'elle est employée en mode client/serveur. Comme le BDE n'est pas optimisé pour cela et dBase encore moins, il y a énormément de problèmes d'index cassés, de tables qui ne s'implémentent pas correctement, d'info pas ou mal transmises aux clients, etc...

Cette application doit être reprise complètement prochainement (peut être changement de système pour aller vers Windev/Hyperfile ou on reste sous Delphi mais avec Postgres ou FireBird).

J'ai lu avec attention les différents post sur le paramétrage du BDE dans ce forum par exemple ici ou là. Avant de "revisiter" cette application il doit encore y avoir au moins un patch correctif à déployer. Du coup je me pose la question suivante : est-ce que cela vaut le coup de passer 2 ou 3 jours pour migrer vers paradox à la place de dBase ? Paradox à l'air plus robuste que dBase en utilisation réseau et a mon avis selon les premiers essais faits cet après midi, l'effort de migration doit être minime (les composants d'accès et d'interrogation de la base sont les mêmes, seule l'extension des nom de table change et mes premiers bout de code montrent qu'il est possible de récupérer les index des tables dBase de manière dynamique pour les "transférer" vers les nouvelles tables paradox : j'aurai encore quelques questions à poser là dessus mais cela dépendra aussi un peu de vos réponses sur la pertinence de la migration)

Merci d'avance pour vos conseils avisés ;)
20/05/2009, 22h21
chaplin

Citation:

Le problème est qu'elle est employée en mode client/serveur

C'est Firebird qui est le plus adapté, en revanche, il faut rajouter du code pour gérer les transactions. Mais aucun soucis pour tenir la charge, en plus tu peux créer des procédures stockées. C'est largement mieux que Hyperfile.

Vaut mieux virer la BDE et prendre des composants dédiés.
C'est vrai que Windev a de superbes écrans, mais avec les composants du pack TMS Smooth Controls, franchement, Delphi ratrappe son retard au niveau du look, car c'est bien sur ce point qu'il pêchait le plus.

Ensuite, il ne faut pas voir le coup de la license mais la souplesse de l'EDI. Avec le recul, j'aurais fait appel à un consultant/expert Delphi pour être assisté dans le projet. C'est savoir investir pour avoir un meilleur retour sur investissement. Enfin, c'est un avis personnel qui n'engage que moi, mais si l'équipe est réduite, c'est un point à prendre en compte pour l'assistance développement.
20/05/2009, 23h09
Sitas

Merci Chaplin pour ton avis sur la question.

L'équipe est plus que restreinte puisque je suis seul ! La migration vers Windev risque de m'être imposée puisque nous faisons appel à un développeur extérieur qui s'en sert. J'ai commencé à explorer la voie Postgres avec bonheur (FireBird me tente aussi mais je pars de plus loin et j'ai cru lire par ici et par là que les composant IB n'étaient plus franchement adaptés et que les freewares UIB n'autorisaient qu'un acces en lecture).

Il est clair et net que l'on va virer le BDE mais la question est de savoir si avant la grande migration (dans 2 mois) cela vaut le coup de passer par Paradox en lieu et place de dBase...
21/05/2009, 08h39
SergioMaster

Citation:

la question est de savoir si avant la grande migration (dans 2 mois) cela vaut le coup de passer par Paradox en lieu et place de dBase...

ma réponse serait NON quoi très rapide à faire, je ne pense pas que cela améliorera de beaucoup les problèmes

et je suis totalement d'accord avec Chaplin pour Firebird

Je rajouterais une couche : je ne crois pas que passer de DBase a Paradox changerait quoique ce soit il faudra quand même utiliser BDE

De mon expérience
1- j'ai des applis Firebird qui tourne avec BDE avec 20 postes en local (tant que ça passe pas par Internet pas de soucis)
2- il existe d'autres composants que ceux que tu cites pour l'utilisation de Firebird avec Delphi gratuits (comme ZEOS dont je suis assez content) ou payant (comme Fib+)
3-pour une migration douce je recommanderais ZEOS qui a beaucoup de points commun avec BDE mais qui peut être également aussi sophistiqué que Fib+

pour plus d'informations , j'accepte les mp ;)

[edit] le moins de la solution windev est aussi que hyperfile est loin d'être une SGBD ouverte mais je ne suis peut-être pas totalement objectif
21/05/2009, 09h46
JP.NUAGE

Et une couche de plus :

J'avais 3 applications en dBase DOS ! Donc condamnées à mourir. Je ne connaissais pratiquement pas Delphi. En 4 mois j'ai converti 80 % des applis. Seul regrêt, je ne connaissais pas ZEOS et je me rends compte maintenant que j'aurais gagné un temps ENORME et évité de pb stupides en utilisant ses composants.

Je me suis même amusé à récupérer des bouts de code dBase pour les 'transcire' en Delphi : peut être pas la meilleure solution mais pratique pour ensuite évoluer vers du Delphi plus 'clean'. Je rejoins donc SergioMaster.

Et idem pour les MP:lol:

Petit PS : j'ai un programme qui convertit les bases dBase en Firebird !
21/05/2009, 10h20
chaplin

Citation:

Conformité ACID et Firebird

Les quatre principes ACID sont l'atomicité, la cohérence, l'isolement et la durabilité.

Atomicité

L'atomicité garanti qu'il n'y a que deux résultats possibles pour une tâche (que l'on nomme transaction)
qui implique des changements de multiples ensembles de données interdépendants : soit toutes
les étapes ont été réalisées correctement et le résultat peut être validé dans la base comme une seule
entité ou, si l'une des étapes n'a pas été réalisée, toutes les autres étapes doivent être défaites (“rolled
back”), laissant l'état de la base inchangé.
L'atomicité est manifestement d'une extrême importance dans les systèmes financiers, où des balances
non équilibrées du fait d'échecs partiels seraient une catastrophe. Les tableurs et les bases de données
qui ne supportent pas les transactions ne peuvent pas être atomiques.
Firebird est entièrement “piloté par les transactions”: rien ne peut arriver en dehors du contexte d'une
transaction.

Cohérence

La Cohérence est la capacité du moteur de bases de données à protéger la base de tous les changements
d'état qui pourraient laisser un ensemble de données désynchronisé par rapport à un autre ensemble
de données. Par exemple, le système doit être capable de reconnaître qu'une facture est liée à
un client et aux éléments facturés. Il doit être capable d'éviter, par exemple, la suppression d'un client
s'il existe encore des factures pour ce client, et la suppression d'une facture qui a des éléments
associés.
L'implémentation pratique de telles dépendances est faite par la déclaration de contraintes d'intégrité
référentielles (“foreign keys”) renforcée par des déclencheurs automatiquement générés. (Les
déclencheurs sont automatiquement générés ou définis dans des blocs de code qui s'exécutent quand
un enregistrement est inséré, modifié ou supprimé.) Le système de bases de données qui dépend du
code d'une application pour gérer des règles de cohérence ne sont pas conformes à la règle de
cohérence ACID. Firebird respecte parfaitement les règles d'intégrité définies par la norme.
Firebird garanti aussi la cohérence quand une seule transaction est exécutée pour effectuer des
changements sur plusieurs bases à la fois, c'est ce que l'on appelle le “two-phase commit”. Les
systèmes qui peuvent accéder à plusieurs bases à la fois de manière concurrente sans la possibilité de
synchroniser les changement dans toutes les bases ne respectent pas le principe de cohérence.
Note
Firebird ne gère pas les déclaration d'intégrité référentielle multi-bases. Chaque base impliqué dans
une transaction multi-bases est responsable de ses propres contraintes référentielles.

Isolement

L'isolement décrit la possibilité du moteur de bases de données de permettre à chaque utilisateur (ou
transaction) d'opérer comme s'il était le seul utilisateur (ou la seule transaction). Le mécanisme
d'isolement doit être capable de garder la base cohérente pour chaque transaction tant qu'elle est en
cours, indépendamment de tout changement intervenant dans d'autres transactions. Les systèmes de
gestion de bases de données qui sont conformes à ce principe offre en général différents niveaux
d'isolement, qui sont définis dans les normes ISO/ANSI SQL.
En plus du niveau d'isolement décrit ci-dessus (Concurrency ou Repeatable Read), qui doit être
supporté, Firebird supporte aussi Read Committed (quand une transaction peut voir le travail validé
par les autres transactions) et, à contrario, Consistency ou Table Stability (quand une transaction qui
peut écrire dans la base bloque l'accès aux tables qu'elle utilise aux autres transactions capables
d'écrire ).

Durabilité

La durabilité garanti que la base va garder trace des changements en cours de manière que l'état de la
base ne soit pas affecté si une transaction est interrompue. De sorte que, même si le serveur de base de
données est débranché en plein milieu d'une transaction, les serveurs de base de données conformes à
la norme ACID doivent remettre la base dans un état cohérent à leur redémarrage.
Journal des Transactions
La durabilité est l'un des principes les plus difficile à respecter. Les autres systèmes de base de
données qui se disent ACID gèrent traditionnellement cela en enregistrant les transactions non
validées dans un journal des transactions. Cependant, l'utilisation d'un journal de transaction n'a jamais
totalement garanti la durabilité, puisque le fichier journal lui même peut être lui même corrompu
logiquement ou physiquement par l'événement qui a interrompu la transaction.
Certains des SGBD qui reposent sur une solution de fichier journal pour satisfaire à la durabilité essaient
de réduire les risques en utilisant des “write-ahead log” pour enregistrer les informations avant
d'essayer de valider les changements. Si ce type de journal survit sans dommage, il peut être possible
de retrouver le travail non validé quand le système se remet en marche et utiliser cette information
pour remettre la base dans un état stable et la remettre dans l'état où elle était avant le problème. De
tels systèmes sont caractérisés par la nécessité d'avoir de longues “procédure de remise en état” après
des erreurs réseau ou des pannes électriques.
Certains produits SGBD sophistiqués sont notoirement connus pour leurs problèmes liés à la restauration
à l'aide des journaux générés lors de l'interruption des transactions. L'instabilité de ces moteurs de
bases de données est telle que, même sur des sites avec des équipements moyens, il est nécessaire
d'employer des équipes pour surveiller en permanence le serveur pour éviter les problèmes et corriger
les incohérences avant que les problèmes ne se propagent trop loin et assurer l'intégrité des données.
L'Architecture Multi-Générationelle de Firebird
L'architecture de Firebird permet de se passer de fichiers journaux car elle garde la version précédente
de chaque enregistrement modifié ou supprimé, pas seulement le temps que la transaction existe, mais
tant que toutes les transactions qui étaient “intéressées” par cet enregistrement, quelle qu'en soit la raison, aient fini leur travail. Le terme utilisé pour cela est “architecture multi-générationelle”, ou
MGA.
MGA était une spécificité unique d'InterBase pendant environ 10 ans jusqu'à ce que cela soit imité par
Oracle. Une fois que le code source de Firebird a été disponible, PostGreSQL l'a copié. Plus
récemment, Microsoft a introduit MGA dans la dernière évolution de SQL Server.
Journal des transactions et Firebird
Firebird n'a pas besoin de journal de transaction pour effectuer des réparations et il n'a pas de
fonctionnalité de journaux de transactions dans son moteur. Toutefois, si une entreprise à besoin
d'enregistrer des journaux pour des besoins d'audit, d'excellents outils existent et sont disponibles chez
des distributeurs tiers de solutions logicielles.

C'était un extrait du Livret blanc sur Firebird.

Bien entendu, il y a les poids lourds du SGBDR, mais satisfaire aux norme de l'ACID est une garantie de très haute qualité du SGBDR, d'ailleurs en lisant en profondeur, on remarque qu'il a inspiré d'autres éditeurs.
21/05/2009, 15h52
VLDG

Pour convertir en Firebird, tu peux aussi utiliser l'utilitaire suivant DatabaseComparer

http://www.clevercomponents.com/down...bcdownload.asp
22/05/2009, 09h18
Sitas

Merci à tous pour vos réponses et vos conseils. Cela va parfaitement dans le sens que je voulais donner à la "grande" migration. Ceci dit, à part SergioMaster et un peu Chaplin, vous ne répondez pas à la question ;) :aie: (ou alors j'ai mal compris et vous me conseillez tous de ne pas passer par la migration intermédiaire ? :oops: )

Trève de "chambrage", je vous remercie beaucoup par rapport aux conseils sur l'utilisation de FireBird. Effectivement j'avais oublié de citer Zeos dans la liste des composants... DataBase Comparer en particulier (mais les composants de chez CleverComponents de manière générale : je pense aussi à DataPump) ont l'air d'une très grande qualité. Malheureusement le responsable projet étant un farouche défenseur de Windev je n'aurais pas 1 centime de marge de manoeuvre si je veux le convaincre de garder notre appli principale sous Delphi. (forcement, il n'est pas développeur et d'un seul coup d'un seul il a entre les mains un soft qui à l'énorme qualité de permettre de manière très simple et très directe à un néophite de développer une appli avec base de données). Pour ma part je suis intimement persuadé que l'effort de migration va être plus important en passant à Windev qu'en restant sous Delphi et en migrant uniquement la BDD et en investissant quelques euros dans l'achat de composants graphique tels que ceux de TMS pour rafraichir le look de l'appli...

Ceci dit je repose ma question : est-ce qu'avant cette grande migration, une "petite" migration intermédiaire de dBase vers Paradox est pertinente ou pas ? Surtout en ce qui concerne la stabilité et la fiabilité de la base dans un fonctionnement réseau multipostes (5 à 6 postes maximum, 2 ou 3 en routine).
22/05/2009, 10h09
SergioMaster

mais pourquoi ne pas faire "simplement" une petite migration de DBase a Firebird en utilisant toujours BDE (malgré mes réserves) .

C'est petite migration sera toute a ton avantage :

peu de modifications du programme
fiabilité de la base
cout néant si ce n'est le temps de modifications

Citation:

Pour ma part je suis intimement persuadé que l'effort de migration va être plus important en passant à Windev qu'en restant sous Delphi

+1

Citation:

le responsable projet étant un farouche défenseur de Windev

évidemment là y a problème mais Windev est loin d'être donné ;) mais évidemment les promos sont intéressante , pour l'achat de windev un pc gratuit par exemple :mouarf:

Citation:

(forcement, il n'est pas développeur et d'un seul coup d'un seul il a entre les mains un soft qui à l'énorme qualité de permettre de manière très simple et très directe à un néophite de développer une appli avec base de données)

"et la marmotte elle met le papier alu autour de la tablette"
bien que en partie vraie , dès que l'on commence a vouloir des applis un peu plus costaud , le néophyte il va se planter :aie:
et là, il y a de la formation a mettre en oeuvre donc coûts

enfin , je ne suis peut être pas totalement objectif
22/05/2009, 10h52
Sitas

Citation:

Envoyé par SergioMaster

mais pourquoi ne pas faire "simplement" une petite migration de DBase a Firebird en utilisant toujours BDE (malgré mes réserves) .

C'est petite migration sera toute a ton avantage :

peu de modifications du programme
fiabilité de la base
cout néant si ce n'est le temps de modifications

Ok, j'avais pas vu ça sous cet angle ! Mais otes moi d'un doute, ça veut dire que tu peux attaquer une base FB avec les composants de l'onglet BDE (TTable, TQuery, TSession entre autres) sans qu'il y ait trop de squetches au niveau de la gestion des accès concurrentiels, du rafraichissement et de la mise à disposition des données (tu me diras pour faire pire que le couple dBase/BDE en réseau il faut faire fort) ?!?

Citation:

Envoyé par SergioMaster

évidemment là y a problème mais Windev est loin d'être donné mais évidemment les promos sont intéressante , pour l'achat de windev un pc gratuit par exemple

Citation:

(forcement, il n'est pas développeur et d'un seul coup d'un seul il a entre les mains un soft qui à l'énorme qualité de permettre de manière très simple et très directe à un néophite de développer une appli avec base de données)

"et la marmotte elle met le papier alu autour de la tablette"
bien que en partie vraie , dès que l'on commence a vouloir des applis un peu plus costaud , le néophyte il va se planter
et là, il y a de la formation a mettre en oeuvre donc coûts

enfin , je ne suis peut être pas totalement objectif

Ben pour les licences c'est déjà fait (contre mon avis) ! Il faut reconnaitre (pour essayer d'être totalement objectif) que nous avons l'appui d'un développeur externe qui développe sous Windev depuis des années (c'est loin d'être un argument négligeable). Après d'un point de vu purement technique cela n'empèchera pas de devoir se "pelucher" toutes les traduction des routines de calcul (on fait de l'acquisition de donnée en temps réel). Mais bon l'argument principal (pour l'instant) il n'est pas raisonné, c'est simplement que le chef de projet est content d'avoir un nouveau jouet sous la main et de pouvoir mettre son nez dans les développements (comme un grand !).
22/05/2009, 11h48
dd_garion

J'ai une appli qui travail avec le BDE et attaque une DB Firebird et ça fonctionne à merveille. Tu as ton Alias BDE DBBase que tu transforme en alias BDE Firebird et le reste suit (sauf horreur de ma part).

Mais, le BDE se meurt ... donc a terme il faudra de toute manière envisager la modification du code.
22/05/2009, 12h17
Sitas

Citation:

Envoyé par dd_garion

J'ai une appli qui travail avec le BDE et attaque une DB Firebird et ça fonctionne à merveille. Tu as ton Alias BDE DBBase que tu transforme en alias BDE Firebird et le reste suit (sauf horreur de ma part).

Mais, le BDE se meurt ... donc a terme il faudra de toute manière envisager la modification du code.

Merci pour ton retour d'expérience dd_garion.

J'imagine que tu utilises le pilote "INTRBASE" de l'administrateur BDE quand tu crée ton Alias (j'imagine sans peine qu'il faut configurer convenablement les entrée "SERVER NAME" et "USER NAME" mais à part ça ?). Y a t'il une "feinte" ou un paramétrage particulier pour le fonctionnement multi poste (a part le LOCAL SHARE à true dans la configuration de l'INIT du BDE) ?
22/05/2009, 12h24
chaplin

Citation:

WINDEV intègre un éditeur d’Analyse (au sens conception de la base de données).
L’élève ingénieur va ainsi facilement :
- apprendre les différents concepts de base de données
- connaître les différentes étapes de la conception d’une base de données.

Avec WINDEV il est possible de réaliser une analyse MERISE (MLD et MCD) sans connaître MERISE et un modèle UML sans connaître UML grâce aux différents assistants.
Un éditeur de modélisation « souple » permet de modéliser les besoins de « maître d’ouvrage » sans devoir se contraindre à l’apprentissage d’une quelconque méthode de modélisation informatique.

Quelqu'un peut m'expliquer comment on peut faire de la modélisation en s'appuyant sur un SGBDR sans connaître Merise, je ne parle même pas d'UML.
22/05/2009, 12h29
dd_garion

NON. :aie:

J'utilise le pilote firebird qui est fournit avec (FBClient.dll et non gds32.dll). Et j'utilises l'ODBC. J'ai cru lire qu'il y avait risque d'incompatibilité.
J'utilise un alias qui pointe vers la db Firebird, cet alias pouvant être ajouté dans le fichier aliases.conf qui se trouve dans le répertoire de firebird.

En ce qui concerne ta question suivante :

Citation:

Y a t'il une "feinte" ou un paramétrage particulier pour le fonctionnement multi poste (a part le LOCAL SHARE à true dans la configuration de l'INIT du BDE) ?

je la laisse aux experts.
22/05/2009, 12h35
dd_garion

Citation:

Quelqu'un peut m'expliquer comment on peut faire de la modélisation en s'appuyant sur un SGBDR sans connaître Merise, je ne parle même pas d'UML.

... je suppose, qu'il suffit d'exprimer ce que le veux et que windew se charge de créer les tables entités/associations et le modèle logique.

Mais le problème de ces outils, c'est que si on a pas les bases de Merises, comment peut-on être sûre de donner toutes les infos et comment vérifier le résultat.

Je rejoints Chaplin dans sa perplexité quand à la magie de cet outil :oops:

C'est comme si je faisait la maçonnerie de ma maison (combien temps cela durerait-il ? et cela tiendrait-il des années ?)... à méditer:D
22/05/2009, 14h40
SergioMaster

Citation:

Mais otes moi d'un doute, ça veut dire que tu peux attaquer une base FB avec les composants de l'onglet BDE (TTable, TQuery, TSession entre autres) sans qu'il y ait trop de squetches au niveau de la gestion des accès concurrentiels, du rafraichissement et de la mise à disposition des données

J'ote le doute , bien que je ne comprenne pas bien le "squetches"

et je rejoint dd_garion en disant que le plus "gros" sera de modifier l'alias BDE (enfin là j'exagère un peu)

Citation:

J'imagine que tu utilises le pilote "INTRBASE" de l'administrateur BDE quand tu crée ton Alias (j'imagine sans peine qu'il faut configurer convenablement les entrée "SERVER NAME" et "USER NAME" mais à part ça ?). Y a t'il une "feinte" ou un paramétrage particulier pour le fonctionnement multi poste (a part le LOCAL SHARE à true dans la configuration de l'INIT du BDE) ?

Absolument pas de feinte et oui pour la question précédente

En fait le plus gros du boulot sera de copier les données de DBASE vers Firebird et donc avant cela de recréer les structures de table .

Quand a l'expérience de l'utilisation du couple BDE/Firebird je te l'ai déjà écrit, j'ai une grosse appli (gestion de production,commerciale et facturation en bref un ERP ) qui fonctionne avec 20 postes en local et depuis son passage en FIB 1.5 (2.0 et 2.1 dans d'autres sites plus petits)
elle tourne comme une horloge (bon pas tout a fait , mais nul n'est parfait ni les utilisateurs ni ma programmation et il y a toujours le cas particulier qui ....)