Discussion :

[jesusnavas]

Bonjour, je migre des applications delphi / access vers firebird, mais je me demandais ce qui était le mieux pour attaquer ma base firebird, parce que entre FIB, UIB, ODBC etc... je suis un peu perdu.

Vu que j'utilisais Access avec ODBC, le moins contraignant et de passer par l'ODBC, mais est ce aussi fiable que les composants spécialisés pour firebird ???
Et apparemment il y a des composants payant, les composants FIB et autres gratuit sont ils aussi fiables ???
Pour les outils d'administration de firebird c'est un peu les mêmes problèmes...

Bref, si quelqu'un qui a de l'expérience sur le sujet pouvait me donner les bons conseils pour me lancer sans tout devoir reprendre dans 2 mois ça serait vraiment cool.

[jesusnavas]

Avant de me faire taper sur les doigts, j'ajoute juste que j'ai vu des éléments de réponse dans différentes discussions du forum, mais j'aurais aimer pousser le débat jusqu'à savoir de quel manière on travail de quel façon. Moi je suis un adepte de travaillé en mode lié à la base, je trouve ça plus naturel et normal. Mon collègue lui est super contre.
Bref, quels composants utiliser avec quel manière de faire, sans rentrer dans le détail de la programmation...

J'espère ne pas avoir embrouillé tout le monde.

[ShaiLeTroll]

Ton Collègue a bien raison, si un jour le choix de la DB change ... deplus, on peut supposer que c'était ACCESS via ODBC avec les composants ADO de Delphi ? Une autre raison, tu auras plus facilement des personnes pour t'aider avec les composants comme ADO qu'avec les composants trop spécifiques ...

ADO est le plus générique, ... d'ailleurs Microsoft recommande ADO.NET

Les composants IB sont plus spécifiques, il fonctionne bien avec InterBase ou FireBird, mais quelques petites astuces sont à savoir comme le prepare ...

Je connais moins, mais tu as encore DBExpress qui utilise des drivers spécifiques que l'on peut trouver chez CoreLab par exemple ...

D'ailleurs CoreLab a aussi ses composants DB ... je les utilise pour MySQL ... car MySQL et ADO, en 2004, cela ne faisait pas bon ménage ...

En fait, il s'utilise tous de la même façon, selon le modèle du DataSource \ DataSet classique, ... et c'est justemet les détails de la programmation qui sont la source de tous les problèmes ...

[jesusnavas]

J'utilisais le BDE et ODBC.

Pour ce qui est du mode connecté ou déconnecté :
1 - Lui me dit que je bloc les autres utilisateurs par exemple si je travail sur une commande. Moi je lui dis que si je suis en consultation je bloc personne, et si je suis en modification, je préfère bloquer ma commande et travailler dessus en étant sur que personne la modifie entre temps. Ou pire, je modifie ma commande, un autre l'ouvre avant que je valide et la referme après moi. Il va m'effacer toutes mes données sans même que je m'en rende compte. V'la le danger pour des tables importantes. Tu me diras sans doute qu'il y a possibilités de mettre des verrous en mode déconnecté aussi, mais bon, je trouve ça fastidieux. Donc pour l'intégrité des données, je préfère être connecté.
2 - Quand mon collègue met une sous table à jour (dans beaucoup de cas), genre les lignes d'une commande, pour pas se faire chier comme il dit, il efface toutes les lignes et les recrées parce qu'il arrive pas avec sa grid à savoir ce qui est modifié, supprimé ou ajouté. Moi en mode connecté, je modifie en live et si je touche une ligne je modifie qu'une ligne. Si il a des clefs numéro auto tu vois le bordel que ça peut lui mettre... D'ailleurs il utilise plus de clef étrangères en partie à cause de ça. Il perd quand même une grande richesse offerte par le SGBD.

Bref, je comprend ce qu'il veut dire, quand il me parle des avantages d'être déconnecté, mais l'apport me parait bien pauvre vis à vis des avantages. J'aimerais bien savoir si entre guillemet, c'est lui qui s'y prend un peu mal ou si réellement tu te frottes à ce genre de choses en mode déconnecté.

Pour ce qui est de la connexion en elle même, l'ODBC et le BDE c'est la solution de facilité, mais je perd le portage, je suis dépendant Microsoft et si par la suite l'ODBC n'est plus fait chez Microsoft je me retape tout comme toujours. Ca ça commence à me saouler...
Bref, si j'utilise UIB, est ce que j'ai une meilleur garantie en therme de pérénité et/ou de portabilité ou ça reste théorique ? Comment vous voyez la chose ?

P.S : La portabilité en Delphi j'y compte pas trop remarque, à tord ou à raison... La pérénité et la fiabilité sont les arguments que je veux privilégier.

[TryExceptEnd]

Avec Firebird, qui est un SGBDR, on travaille par des transactions, ça veux dire que quelque soit notre requete, elle se fait au sein d'une transaction (ouverture d'une transaction->Requete->fermeture de la transaction).
Le meilleur moyen de travailler avec cette méthode est avec des composants qui permettent le mode déconnecté avec la mise en cache des données (en mémoire).
Le mieux est aussi d'avoir des composants fait pour Firebird et suivant ses évolutions pour être toujours au plus prés du serveur.
Enfin, de mon expérience, je recommande les composants UIB; De par leur fiabilité, leur évolution parallèle a firebird et leurs rapidité, pour moi c'est les plus costauds pour "attaquer" un SGBDR, genre Firebird.

[Franck SORIANO]

Ton Collègue a bien raison, si un jour le choix de la DB change ... deplus, on peut supposer que c'était ACCESS via ODBC avec les composants ADO de Delphi ? Une autre raison, tu auras plus facilement des personnes pour t'aider avec les composants comme ADO qu'avec les composants trop spécifiques ...

ADO est le plus générique, ... d'ailleurs Microsoft recommande ADO.NET

Je suis d'accord avec l'idée générale, mais attention : ADO et ADO.NET n'ont en commun que le nom. Il s'agit de deux technologies radicalement différentes.

si par la suite l'ODBC n'est plus fait chez Microsoft

Je te rassure tout de suite, ça doit bien faire 10 ans que Microsoft a abandonné ODBC pour le remplacer par OLEDB complété par ADO. Comme toujours, l'existant ne va pas disparaitre du jour au lendemain mais je ne pense pas que partir sur de l'ODBC maintenant soit une bonne idée.
De même, le BDE est censé ne plus exister chez borland depuis dbExpress et Delphi 6...

Pour ce qui est du mode connecté/déconnecté je dirais que c'est deux approches différentes du problème. Chacune avec ces avantages et ces inconvénients.
Moi je fais plutôt du déconnecté. Ca consomme moins de ressource sur le serveur (on ne garde pas d'objets ouvert sur le SGBD). On peut mettre en place des caches et ainsi optimiser les accès à la base (et donc les performances)...

Lui me dit que je bloc les autres utilisateurs par exemple si je travail sur une commande. Moi je lui dis que si je suis en consultation je bloc personne

Ben là, tout dépend du SGBD, du mode d'isolation des transactions...
Selon les cas, tu peux avoir raison, tout comme tu peux bloquer les autres utilisateurs simplement parce que tu es en train de lire une donnée.

Par exemple, considère la transaction suivante : Je crédite le solde d'un compte d'un certain montant.
1. Je lis l'ancien solde.
2. Je calcule la nouvelle valeur du solde.
3. Je modifie le nouveau solde.

Il vaudrait mieux que personne ne vienne modifier le solde après que tu l'ai lu et avant que tu n'es écrit la nouvelle valeur, sinon tu vas perdre des données.
Un SGBD peut très bien verrouiller une ligne, une page, voir une table suite à une lecture. Ca dépend comment vous travaillez.

[VLDG]

en anglais :

http://www.firebirdfaq.org/faq7/

A ma connaissance UIB et FIBPlus fonctionnent très bien.

Si c'est une migration du BDE, le plus simple est je pense FIBPLUS.

[jesusnavas]

Merci pour toutes ces précisions, je vais donc commencer par écarter la solution BDE, ODBC qui semble bien obsolète, dommage, ça me paraissait le plus simple niveau programmation.
Coté composant, FIBPlus est payant, j'ai une version de démo, mais quel merde, pleins de message...
UIB, j'arrive pas à l'installer. La c'est à moi de me remettre en question.
ADO je garde une Microsoft dépendance que j'aime pas trop, il vont me le mettre bien profond de nouveau dans quelques années.
Bref, si je pars sur IBX avec mon firebird c'est possible ? Ca marche bien ? Stable, pérène et efficace ?

[VLDG]

Bref, si je pars sur IBX avec mon firebird c'est possible ? Ca marche bien ? Stable, pérène et efficace ?

IBX ça fonctionne encore (c'est ce que j'utilise) mais conseiller IBX pour Firebird : c'est pas vraiment un conseil avisé !

sinon, tu peux utiliser dbexpress aussi avec les drivers Interbase et basculer sur des drivers qui gèrent mieux Firebird après !

[jesusnavas]

dbexpress c'est quoi exactement ? Une suite de composant aussi ? Comme IBX mais qui te permet de choisir un driver firebird, IB ou firebird embedded c'est ça ?

[Franck SORIANO]

dbexpress c'est quoi exactement ? Une suite de composant aussi ?

dbExpress c'est la nouvelle API définie par Borland à partir de Delphi 6 pour remplacer le BDE.
Son objectif était d'être portable sous Linux (Borland a fait la même pour Kylix), plus légère que les API existantes et plus rapide.

dbExpress se distingue du fait que les DataSet sont unidirectionnels, en lecture seule. Tout est fait pour exécuter une requête et lire le résultat le plus rapidement possible.
dbExpress fait appel à des drivers spécifiques dbExpress pour accéder aux différentes bases de données.

Comme ce n'est pas la façon courante de travailler à avec Delphi, Borland préconise de coupler dbExpress avec un TClientDataSet, par l'intermédiaire d'un DataProvider.
Tu travaille alors en mode déconnecté, sur le ClientDataSet : Ce dernier fait appel à dbExpress pour exécuter une requête SELECT et charger les données de la table en mémoire. Tu modifie le TClientDataSet comme un TTable BDE. Puis lorsque tu décides d'appliquer les modifications en base de données, le TCLientDataSet génère une liste des données modifiées. Il génère alors toutes les requêtes de mise à jour nécessaires et les exécutent dans la base.

Je l'ai déjà utilisé pour SQL Server et Oracle. Il y a de gros problèmes de performances si tu utilises des champs de type LOB (BLOB, Memo...). Je ne sais pas si c'est la même chose avec FireBird, mais j'ai peur que ça vienne de l'architecture dbx.

Je ferais également remarquer que c'est une API Delphi. Je ne crois pas que dbx soit utilisé en dehors de Delphi (et tous les Delphi ne l'utilisent pas !)

[Delfino]

Les MDO son un clone de IBX mais supportant les nouveautès Firebird, (ex fbclient.dll)

[VLDG]

Les MDO son un clone de IBX mais supportant les nouveautès Firebird, (ex fbclient.dll)

j'ai l'impression qu'il n'y a plus trop d'évolution de cette librairie ?

[jesusnavas]

Pas encourageant à utiliser dbexpress tout ça...
Bref, tout ça veux un peu dire que en gratuit seul UIB vaut le coup apparemment. Et si on est près à payer FIBPlus.
Je vais aller jeter un oeil à MDO...

[Delfino]

j'ai l'impression qu'il n'y a plus trop d'évolution de cette librairie ?

Je crois que les auteurs sont entrain de convertir la librairie pour la faire compatible avec FreePascal/Lazarus..

[SergioMaster]

Pour ajouter mon grain de sel :

mes programmes en D3 (eh oui) fonctionne tres bien via BDE avec une Base FIB2
toutefois au niveau performances en LAN ça peut aller a dire par contre WAN bonjour les dégats .

L'entreprise pour laquelle j'avais fait ces programmes (avant 2000 ) passant du LAN au WAN (via ligne specialisée) je migre petit a petit ces applis .

J'ai préféré utilisé FIBPlus pour cela plutot que UIB (à cause de mes habitudes de programmation , et pour faire plus facilement la migration de BDE )
et surtout IBX (parcequ'il se lisait sur la toile que ceux-ci ne serait plus garantis compatibles avec les nouvelles versions de FIB , apparemment ce serait le cas mais uniquement pour la gestion de la base elle-même pas pour les accès aux données .....)

[Franck SORIANO]

mes programmes en D3 (eh oui) fonctionne tres bien via BDE avec une Base FIB2
toutefois au niveau performances en LAN ça peut aller a dire par contre WAN bonjour les dégats .

De toute façon je pense que du client/serveur en WAN, bonjour les dégats. Quelles que soit l'API et les composants utilisés.

[SergioMaster]

De toute façon je pense que du client/serveur en WAN, bonjour les dégats. Quelles que soit l'API et les composants utilisés.

tu as raison , mais quel solution proposerais-tu pour un client qui :
"veux que cela marche tout de suite " ou plus tôt pour hier "avec les programmes existants" sachant qu'au debut il ne voulait meme pas entendre parler de connection entre les 2 sites (il m'a meme fait la suggestion d'un transfert de données via [bicyclette] USB )

[Franck SORIANO]

D'installer l'appli en TSE ou Citrix sur un serveur avec la base en LAN. L'appli étant alors accessible depuis n'importe ou. Ca marche tout de suite. Pas de modif d'appli à faire et sa simplifie la maintenance puisqu'il n'y a plus qu'un serveur à maintenir au lieu de n postes.

Nous c'est ce qu'on fait.

[VLDG]

Nous c'est ce qu'on fait.

on fait aussi mais ce n'est pas une fierté.

Donner tout ce pognon a Bill c'est un peu frustrant !

Mais, ça fonctionne relativement bien

je pense que pour une nouvelle application : je regarderai du coté de www.remobjects.com avec peut être un accès ANYDAC qui je l'espère permet une bonne intégration avec leur outils de développement multi tiers