Oracle, BDE -> ADO ou dbExpress?

Version imprimable

11/10/2011, 09h01
vedge2000

Oracle, BDE -> ADO ou dbExpress?

Bonjour,

j'ai actuellement Delphi 2007 et je voulais migrer sur le XE2 prochainement (ça va être chaud malgré que j'ai quasi que des composants de base!!!).

En plus de cela j'ai une vieillerie en Oracle et le 'super' BDE ou mes clients commencent à passer en Windows 7 x64.

Donc j'ai pas trop le choix (et il faut le faire un jour), je vais migrer fur à mesure mon BDE en Ado ou dbExpress en Delphi 2007 avant de migrer en XE2

Par contre je ne sais pas le quel je dois prendre entre le ADO et le dbExpress (avantages/désavantages)!

Est-ce que quelqu'un pourrait me donner un/des avis?

Merci d'avance!
11/10/2011, 10h14
ShaiLeTroll

ADO conservera un comportement plus proche du BDE, la nature unidirectionnel de DBExpress peut dérouter ainsi que sa gestion du cache !

Ensuite, tout dépend ton code, si tu as utilisé bcp de SQL paramétrée avec des relations Maître\Détail, à part quelques ennuis sur les dates dans le Filter (une erreur genre : une opération en plus étape a échouée), j'ignore si l'anomalie a été corrigée mais durant une migration similaire, j'ai découvert un "bug" de l'ADO par rapport à BDE : ORACLE même SQL lancé via BDE ou ODA = DataSet différent
Donc a part, ces petits problèmes, la migration peut-être assez simple, surtout que dans mon cas c'était Paradox+BDE vers Oracle+ADO, si tu es déjà en Oracle, tu as surement déjà éviter le TTable au profit d'un TQuery

Par contre, si tu as abusé du TTable, si tu as une volumétrie importante, tu pourras avoir des soucis de performances, idem si tes TQuery récupère bcp d'enregistrements !
Il faut étudier la gestion de la récupération des enregistrements par paquet !

Pour DBExpress, étudie le TClientDataSet\TDataSetProvider ou le wrapper TSimpleDataSet !
Pour les mises à jour, encore le soucis, as-tu manuellement géré tes mises à jour via des SQL INSERT\UPDATE ou utilisé Edit\Append\Post ?
Avec le BDE, on avait le TSQLUpdate,
en ADO, je ne sais pas ce qui le remplace
en DBExpress, c'est via BeforeUpdateRecord que l'on peut effectuer ses propres mises à jour manuelle !

Si il y a des experts en la matière, cela m'interesse aussi, là où je suis, on utilise le Cache mais sans jamais faire de Post et le programme va utiliser un SQL paramètré prédéfini (un peu comme un TSQLUpdate à la main) ou alors le SQL est généré à la volée.
11/10/2011, 10h58
vedge2000

Salut ShaiLeTroll,

Merci de ton message!
Oui j'ai pas mal de SQL paramétré mais c'est pas très compliqué (client--> courrier,...)!
Sinon, je n'ai pas de TTable ;)
Les seuls gros Query qui ramènent beaucoup d'enregistrement (60'000) sont très facilement modifiable (c'est pour afficher tous les clients au démarrage)

Et malheureusement, les updates se font pas encore avec le TSQLUpdate mais c'est n'est pas sorcier de les rajouter!

Tu partirais donc avec de l'ADO?

Merci encore!
11/10/2011, 11h47
ShaiLeTroll

Citation:

Envoyé par vedge2000

Les seuls gros Query qui ramènent beaucoup d'enregistrement (60'000) sont très facilement modifiable (c'est pour afficher tous les clients au démarrage)

Oui, une pratique a éviter ... idem, lors d'une migration DBase vers MySQL, j'ai viré le listing affichant les 500 000 clients contenu dans le logiciel ainsi que le Journal comptable ouvrant les 2 millions de lignes inutilement !
En DBase, le Open était instantané (juste un curseur sur un fichier partagé), sous MySQL (transfert client serveur TCP\IP + BCP de mémoire consommé sur le serveur le temps de la mise en réseau et localement tant que l'on conserve le DataSet ouvert)

TSQLUpdate ou BeforeUpdateRecord c'est pour les jointures "modifiables", si c'est un simple SQL sans jointure comme SELECT * FROM table WHERE PK = :ID normalement, cela fonctionne sans soucis pour la mise à jour !
En général, les listings utilisent des jointures mais la fiche d'édition d'un item va récupérer table par table (en fait c'est l'objet métier qui gère cela), et donc simplifie la mise à jour
11/10/2011, 12h43
vedge2000

merci pour tout!
Je vais regarder cela!
11/10/2011, 21h15
Franck SORIANO

Citation:

Envoyé par vedge2000

Est-ce que quelqu'un pourrait me donner un/des avis?

Ca dépend de ce que tu cherches, de tes objectifs, de tes contraintes et de ton budget...

Si tu travailles avec Oracle, j'aurai tendance à dire que l'idéal c'est d'oublier aussi bien dbExpress qu'ADO pour faire de l'OCI natif...
C'est ce qui donnera les meilleures performances (et la différence peut être énorme, surtout si ton appli fait beaucoup d'accès à la base).
Mais il y a de grandes chances que ça veuille dire tout réécrire...

Personnellement j'ai eu de très mauvaises expériences avec dbExpress. Surtout, lorsque la table contient des champs LOB (CLOB ou BLOB en Oracle). Les performances étaient catastrophiques : Une requête qui retourne 1000 lignes, avec 2 CLOB prenait 16s.
En ADO, la requête prenait 4s.
La même requête en OCI prenait 600 ms.
Bien sûr c'était sur une requête bien précise (malheureusement, qui fait partie du coeur de l'appli). Lorsque tu n'as pas de champs LOB, l'écart de perfs est moins grand.
Je n'ai pas refait le test avec les versions récentes de dbExpress.

Si tu utilises ADO, tu vas te rendre compte que les composants ADO ne sont pas interchangeables avec ceux du BDE. Il ne s'agit pas de grosses révolutions, mais juste ce qu'il faut pour que ce soit très chiant...
Par exemple sur le TQuery, tu passes les paramètres en utilisant une propriété Params et des TParam.
Avec un TADOQuery, la propriété s'appelle Parameters. De quoi être obligé de repasser partout dans le code pour tout changer.

A contrario, si tu travailles avec dbExpress et surtout avec un TClientDataSet ou un TSimpleDataset, les composants sont beaucoup plus proches du BDE et presque interchangeables. Mais c'est au prix des performances...
12/10/2011, 06h51
vedge2000

Salut Franck,
Merci de tes réponses!
Pour le OCI natif, nous ne sommes pas partisants des composants externes, pas pour une raison de coup ou de performance mais en cas de migration ou en cas de non suivi des composants (bref d'être le moins dépendant possible d'autre entreprise qu'Embarcadero)!

Je limite au max les composants, j'ai actuellement que le quickreport et un port com (qui va gicler lors de la migration).

Pour les performances, ce n'est pas un cas critique mais il ne faut pas que cela dérange l'utilisateur. Je vais essayer Ado et plusieurs requêtes pour tester les performances!

Merci de vos conseils!