Discussion :

[Sitas]

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

[chaplin]

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.

[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...

[SergioMaster]

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

[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

Petit PS : j'ai un programme qui convertit les bases dBase en Firebird !

[chaplin]

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.