Discussion :

[Barbibulle]

Bonjour,

J'ai une grosse application de gestion multi-poste écrite avec Delphi 7 qui tourne sous fb2.1 et qui utilise les IBX.

Tout fonctionne correctement, bien entendu je ne peux pas utiliser certaines nouvelles fonctionnalités de FB2.1 (uniquement coté client à cause des IBX). Utilisant beaucoup les procédures stoquées, je ne trouve pas cela gênant.

Cette application utilise principalement (dans le désordre) :

• TIBDatabase
• TIBStoredProc
• TIBDataSet
• TIBQuery
• TIB******Field
• TIBTransaction
  

TDataSource pour connecter tous les composants orientés données comme les devexpress et Fastreport 4 comme éditeur.

Pour le moment je n'ai aucun besoin de migrer, mais peut être un jour je n'aurai plus le choix.

Je viens de refaire un peu le tour des composants de connexion à firebird, et j'aimerai avoir un retour d'expérience et avis sur la question.
Mes critères sont :

• Composants orientés données : (fonctionnant avec devexpress, fastreport 4)
• Gestion des transactions.
• Remplacement facile des IBX et fonctionnement similaire.
• Pérennité des composants.

Si je regarde la liste des outils et composants http://interbase.developpez.com/outils/ (dernière mise à jour décembre 2008)

IBObjects :
http://www.ibobjects.com/
Le site ne répond pas / plus ? Ces composants existent encore ?

FBLib :
http://fblib.altervista.org/
Composants non orienté données, et plus de nouvelle version depuis 4 ans.

FIBPlus :
http://www.devrace.com/en/fibplus/
Composants qui se reprochent des IBX, et donc le remplacement ne devrait pas poser trop de problèmes (Si quelqu'un a déjà migré des IBX vers FIBPlus, j aimerai bien avoir un retour d'expérience)
Par contre quand je vois que la dernière annonce sur leur site date de février 2010, je ne vois rien concernant FB2.5 non plus et sur le forum je tombe sur http://www.devrace.com/en/support/fo...FID=15&TID=664 ce qui n'est pas très encourageant question pérennité. Alors peut être que le produit n'est pas mort mais le manque de communication sur le sujet, n'est pas engageant.

IBDAC :
http://www.devart.com/ibdac/
Composants qui se reprochent des IBX, et donc le remplacement ne devrait pas poser trop de problèmes (Si quelqu'un a déjà migré des IBX vers IBDAC, j aimerai bien avoir un retour d'expérience)
Le support sur leur forum à l'air fiable et les composants assez rapide (un peu en dessous des FIBPlus mais comparable d'après ce que j'ai pu lire).

UIB :
http://www.progdigy.com/
Très performant, gratuit et projet actif mais non orienté données. => La migration risque d'être difficile et longue.

Dbxlda :
http://www.crlab.com/dbx/
Driver dbexpress (=>unidirectionnel) donc migration plus difficile il faut ajouter des composants et code pour avoir un comportement similaire.

Donc mon choix se porterai plutôt sur FIBPlus oubien IBDAC, car ils ont l'air de répondre tous deux à mes critères.
Si je pouvais avoir un retour d'expérience par rapport à ces deux produits notamment dans le cadre d'une migration IBX. (et si quelqu'un sait quelque chose sur le devenir des FIBPlus.)
Merci d'avance à ceux qui voudront bien partager leur expérience.

[qi130]

Le site IBOjects est toujours alive

[makowski]

Fibplus est bien vivant
mais c'est des Russes, le site en version Russe est plus à jour
http://www.devrace.com/ru/fibplus/

[TryExceptEnd]

Il y a trois ans j'ai eu la même problématique pour faire un choix pertinent entre tous ces composants que vous citez (a partir de Paradox).
J'ai fait le choix des UIB + les Datasets de Grizzly qui permettent de travailler en mode déconnecté, ce qui est a mes yeux est primordiale pour gérer mes transactions de façon transparente et fine.
L'utilisation de ces composants est très facile et la migration devrait se faire sans problème.
En plus le concepteur des UIB est hyper actif et réactif, Grizzly l'est moins mais toujours joignable et les deux sont français alors !

[Barbibulle]

Merci pour vos réponses,

Le site IBOjects est toujours alive

Chez moi il ne fonctionne pas, le serveur ne répond pas. Il fait peut être du racisme anti-free.fr

Fibplus est bien vivant
mais c'est des Russes, le site en version Russe est plus à jour
http://www.devrace.com/ru/fibplus/

Ok, Je ne parle pas russe mais je vais regarder quand même.
As tu un avis / préférence ou un retour d'expérience par rapport au choix de ces composants dans le cadre d'une migration IBX ?

Il y a trois ans j'ai eu la même problématique pour faire un choix pertinent entre tous ces composants que vous citez (a partir de Paradox).
J'ai fait le choix des UIB + les Datasets de Grizzly qui permettent de travailler en mode déconnecté, ce qui est a mes yeux est primordiale pour gérer mes transactions de façon transparente et fine.
L'utilisation de ces composants est très facile et la migration devrait se faire sans problème.
En plus le concepteur des UIB est hyper actif et réactif, Grizzly l'est moins mais toujours joignable et les deux sont français alors !

Je n'ai pas besoin d'un mode déconnecté, le progiciel est fait pour travailler directement avec le serveur, sur un réseau local. Il y a principalement des traitements via des procédures stoquées, et finalement les écrans de saisie (qui pourrait fonctionner en mode déconnecté) sont minoritaires. Je ne comprend pas bien la remarque concernant la transaction. Pour moi les transactions sont gérés par le serveur, si on est déconnecté, la transaction est perdu. UIB/Grizzlypack permettrait en se reconnectant de réutiliser la transaction ? Ou bien ce que tu appels transaction c'est un buffer local qui permet de travailler en déconnecté et qui est envoyé au serveur à la demande (dans une seule transaction fb qui est du coup courte) ?

[Cl@udius]

Salut Barbibulle

Je fais l'impasse sur le choix des composants pour effectuer ta migration. Utilisant quasi exclusivement les composants UIB, et comme tu le fais remarquer une migration IBX->UIB n'est pas des plus simples.

Pour moi les transactions sont gérés par le serveur, si on est déconnecté, la transaction est perdu.

Pour moi c'est plutôt l'inverse. C'est l'application qui est responsable du démarrage et validation/annulation des transactions en veillant à ce que celles-ci ne finissent pas dans les 'limbes' (que l'on soit en déconnecté ou non).

[TryExceptEnd]

Je n'ai pas besoin d'un mode déconnecté, le progiciel est fait pour travailler directement avec le serveur, sur un réseau local.
Il y a principalement des traitements via des procédures stoquées, et finalement les écrans de saisie (qui pourrait fonctionner en mode déconnecté) sont minoritaires. Je ne comprend pas bien la remarque concernant la transaction. Pour moi les transactions sont gérés par le serveur, si on est déconnecté, la transaction est perdu. UIB/Grizzlypack permettrait en se reconnectant de réutiliser la transaction ? Ou bien ce que tu appels transaction c'est un buffer local qui permet de travailler en déconnecté et qui est envoyé au serveur à la demande (dans une seule transaction fb qui est du coup courte) ?

Je parlais du mode déconnecté de façon générale qui inclut de travailler avec des Datasets en mémoire qui permettent effectivement le mode déconnecté total mais aussi de fermer les transactions tout de suite après chaque requête sans être déconnecté définitivement du serveur.
De cette façon tu as le contrôle total de tes transactions et tu peux même utiliser le mode SNAPSHOT des transactions qui permet d'avoir comme une copie instantanée de la base de données sur qui la transaction travaille.

[Barbibulle]

Salut Barbibulle

Je fais l'impasse sur le choix des composants pour effectuer ta migration. Utilisant quasi exclusivement les composants UIB, et comme tu le fais remarquer une migration IBX->UIB n'est pas des plus simples.


Pour moi c'est plutôt l'inverse. C'est l'application qui est responsable du démarrage et validation/annulation des transactions en veillant à ce que celles-ci ne finissent pas dans les 'limbes' (que l'on soit en déconnecté ou non).

Salut Claudius,
C'est ce qui me semblait concernant les UIB.
Pour ce qui est des transactions, je me suis mal exprimé, c'est l'application qui les pilote mais c'est le serveur qui les gère.

Je parlais du mode déconnecté de façon générale qui inclut de travailler avec des Datasets en mémoire qui permettent effectivement le mode déconnecté total mais aussi de fermer les transactions tout de suite après chaque requête sans être déconnecté définitivement du serveur.
De cette façon tu as le contrôle total de tes transactions et tu peux même utiliser le mode SNAPSHOT des transactions qui permet d'avoir comme une copie instantanée de la base de données sur qui la transaction travaille.

Ok c'est bien comme ça que je voyais les UIB. Avec des dataset mémoire. C'est de l'unidirectionnel comme les DBExpress.

C'est certainement plus performant et plus propre du fait que les transactions fb sont courtes.
Mais la migration depuis les IBX implique un investissement bien plus important qu'un simple remplacement de composant. J'ai peur également que ca remette en question certain de mes traitements ou gestion de mes transactions. Il faudrait que je teste certains cas de figure avec les UIB pour voir s'il y a des différences.
Bref si j'avais à passer aux UIB, je pense que ca serait plus dans le cadre d'une version majeur de mon progiciel que d'une simple mise à jour.

C'est pourquoi je recherche un retour d'expérience concernant une migration IBX vers FIBPlus/IBDAC car ces composants ont l'air similaire dans leur philosophie d'utilisation.

[TryExceptEnd]

Si tu utilise des composants orienté données comme les DBGrid, tu auras du mal a fermer tes transactions rapidement sans perdre la connexion a la base de données si tu n'utilise pas des Datasets en mémoire et bonjour les dégâts a terme avec cette méthode.

[Barbibulle]

Si tu utilise des composants orienté données comme les DBGrid, tu auras du mal a fermer tes transactions rapidement sans perdre la connexion a la base de données si tu n'utilise pas des Datasets en mémoire et bonjour les dégâts a terme avec cette méthode.

Version courte :
Biiiiiip !! Hors sujet !

Version longue :
Il ne faut pas généraliser non plus... ca fait 4 ans que l'application tourne sans problème.
Ce n'est pas une application avec des centaines de connexion, les services de gestion à qui il s'adresse ne dépasseront jamais plus d'une dizaine de connexion...

J'ai conscience de l'impact des transactions longues (encore qu'il faudrait différencier les transactions de mise à jour des transactions de lecture avant de pouvoir affirmer qu'il va y avoir péril en la demeure...).

Et ce n'est pas le sujet de mon post. Je veux bien ouvrir un autre sujet pour rechercher quelqu'un qui migrerait gratuitement mon application (environ 160 pas/dfm une centaines de tables et environ 400 procédures stoquées), recoder les choses inélégantes (il y en a hélas) et surtout faire des tests de non régression. Mais j'ai bien peur de perde mon temps...

La réalité c'est que mes clients ne voudront jamais payer une mise à jour "Technique" qui n'apportera rien fonctionnellement.

Voilà j'aimerai qu'on revienne sur le sujet initial, parcequ'à cause de la "réalité", "ce qu'il faudrait" ou "ce que j'aimerai" faire n'est pas toujours à ma portée D'où mon critère numéro 3 : "Remplacement facile des IBX et fonctionnement similaire."

[TryExceptEnd]

Ah bon ? Je croyais qu'on donnait un coup de main, sinon tu fait comme tu veux.

[makowski]

Si tu utilise des composants orienté données comme les DBGrid, tu auras du mal a fermer tes transactions rapidement sans perdre la connexion a la base de données si tu n'utilise pas des Datasets en mémoire et bonjour les dégâts a terme avec cette méthode.

ça dépend, si les affichages dans les grilles utilisent une transaction READ ONLY READ COMMITTED RECORD_VERSION, il n'y a pas de problème

[makowski]

La réalité c'est que mes clients ne voudront jamais payer une mise à jour "Technique" qui n'apportera rien fonctionnellement.

ce n'est pas exactement ton cas, mais c'est avec ce genre de raisonnement, que je vois des gens encore utiliser le dialect 1 et le bde et qui pleurent parce que quand il y a une montée en charge leur solution ne tient plus la route

dans ton cas, tu peux faire la migration petit à petit, mais vraiment les IBX sont une voie sans issue.

[Barbibulle]

C'est malheureux mais c'est comme ça. Les gens sont prêt à payer s'ils sont bloqués mais pour anticiper un éventuel blocage c'est une autre histoire. Je ne les blâmes pas, outre l'aspect économique il faut aussi avoir le temps et les ressources de faire ce genre d'évolution.

Je ne vais pas avoir de monté en charge supplémentaire. Seul le volume de la base va augmenter au fil du temps (seulement + 50Mo par année ce qui est relativement faible pour firebird). De plus j'ai des programmes de purge pour éliminer les données les plus anciennes qui me permet de stabiliser la taille de la base.

Je ne suis pas encore au pied du mur concernant l'abandon des IBX. Simplement je dois planifier cette tâche. Je ne souhaite pas que cela me coute trop de temps/argent, c'est pourquoi je cherche un remplaçant "naturel".

[Andry]

Je viens de migrer une petite appli utilisant Interbase 6 vers Firebird 2.5.
J'ai eu le choix sur FIbPlus et UIB.
Au niveau des Dataset, le TpfUbQuery et le TUIBQuery ne sont pas orienté donnée.
J'ai donc que TpfIBDataset et TUIBDataset comme option.
Or d'après ce que j'ai entendu sur le net, la version 7 de FIbPlus est encore trop buggée (j'utilise Delphi XE).
Donc, il ne me reste plus que le TIUBDataset pour remplacer les TIbDataset.
Je dirais qu'il y a quand même du boulot mais le principe reste le même.

Andry

[Cl@udius]

Salut Andry.

Donc, il ne me reste plus que le TIUBDataset pour remplacer les TIbDataset.

A noter tout de même que le TUIBDataSet est en lecture-seule. Seul minime reproche que je fais aux UIB.

[Andry]

Salut Andry.

A noter tout de même que le TUIBDataSet est en lecture-seule. Seul minime reproche que je fais aux UIB.

Ouii, je l'ai aussi remarquer mais de toute façon j'utilisais uniquement les IbDataset pour l'affichage des grille.
Du coup ça a faciliter la migration car mes update/delete/insert ont été faites depuis des TIbQuery.
Juste quelques coup de rechercher/remplacer au niveau des instaciations des query et de certaine propriétés et le tour est joué.

A+

[kaouane]

Sincèrement, les UIB ont une réputation formidable, je doit obligatoirement et sans recul migrer vers ces composants.

[rsc]

IBDAC :
http://www.devart.com/ibdac/
Composants qui se reprochent des IBX, et donc le remplacement ne devrait pas poser trop de problèmes (Si quelqu'un a déjà migré des IBX vers IBDAC, j aimerai bien avoir un retour d'expérience)
Le support sur leur forum à l'air fiable et les composants assez rapide (un peu en dessous des FIBPlus mais comparable d'après ce que j'ai pu lire).

J'utilise depuis quelque temps les composants UniDac du même Devart. La seule différence, je crois, avec IbDAC, est qu'ils me permettent de me connecter indifféremment à des base Firebird, Oracle, PostgreSql... Et j'en suis plutôt content.

Bonne fiabilité, performances très honorables (drivers natifs). Question support, quand j'ai eu une question, les réponses sur le forum Devart étaient rapides et claires.

Il m'est difficile de répondre concernant une migration depuis IBX, puisque je n'ai jamais employé IBX. J'ai migré des applis qui utilisaient le BDE et les composants TTable, TQuery, etc... Disons que les composants Devart sont dans leur usage de base très semblables à ces composants, et que la migration a été très facile.

La plus grande différence résidait dans l'usage d'un composant TUniConnection au lieu du TDatabase du BDE.

Ah ! un problème que j'ai rencontré : les champs de type NUMERIC(x, 0) ou
DECIMAL(x, 0) de Firebird sont interprétés comme champs float. Il faut modifier les bases et les passer en Integer.

Voilà, si ça peut t'aider...

[VLDG]

il y a aussi AnyDAC qui semble pas mal
http://www.da-soft.com/anydac/

Qu'as tu choisi finalement ?