Discussion :

[PaulR]

Bin voilà, tout est dans le titre. Je cherche des gens qui travaillent en Delphi et attaquent directement la DB2 d'un AS400... But ? Sachant que le BDE n'en finit pas de mourir, mais qu'il sera forcément vraiment mort un jour, je voudrais voir l'état de leur réflexion en la matière, discuter des solutions possibles, de leurs performances etc : ODBC, Delphi/400 de Systemobjects, etc...
Il ne me reste plus qu'à croiser les doigts pour que ce message ne flotte pas indéfiniment dans sa bouteille :-)

[ShaiLeTroll]

Delphi/400 EST l'outil Delphi pour cela !
Tu trouveras difficilement plus performant, c'est le métier de SystemObjects, il développe eux-même leur driver DB2 (que l'on peut utiliser via BDE ou ODBC)

Surtout qu'ils ont ouvert leur outil à plus en plus de langage, on peut espérer que leur produit sera pérenne (c'est leur gagne-pain après tout)

ODBC, si tu utilisais le BDE, DB2 était déjà accéder via ODBC (je n'ai pas souvenir d'un driver natif BDE)
Donc ADO ou DBExpress ODBC pourrais-être ce qui s'approche le plus du BDE !

Voir sujet similaire : Quelle connexion à une base DB2 sur AS400

[Papy214]

http://www.easycom-aura.com/article/easycom.html

[skywaukers]

Bonjour,

ADO ou DBXpress avec la couche d'accès données de Client Accès (pas besoin de licence pour l'utiliser) ça fonctionne plutôt bien. A une époque j'avais fait quelques test comparatif de performance entre ça et system object, je n'avais pas trouvé de réelle différence, mais c'était il y a quelques années, je ne parle pas des versions actuelles que je ne connais pas. Pour moi l'avantage des outils de systemobject c'est de proposer des fonctionnalités plus poussées (comme par exemple exécuter un programme sur l'AS400 avec passage de paramètre et récupération de résultat (il devient presque comme une procédure stockée comme cela en fait). Je pense que les outils de Aura proposent des choses équivalentes.
L'inconvénient de ces outils c'est qu'ils obligent à installer une couche sur l'AS400, couche qui n'est généralement plus compatible lors des changement de versions de l'AS400, et donc t'es obligé de repayer une version, ou de prendre une maintenance juste pour avoir la compatibilité avec ta nouvelle version d'OS400. Avec Client Acces c'est plus transparent et sans licence à payer.

@++
Dany

[PaulR]

Merci ShaiLeTroll et les autres.

Nous travaillons avec Delphi/400 depuis une grosse dizaine d'années maintenant et on est vraiment très contents du produit. Simple, stable, rapide, et on travaille avec l'AS400 comme avec n'importe quelle DB du monde PC. Quand on l'avait découvert, on avait trouvé ça magique...

Nous sommes une dizaine de développeurs, pour une solution logicielle maison en évolution permanente depuis 10 ans (nouvelles fonctionnalités, changements de législation, changements métier, nouveaux marchés etc.), qui gère tout, depuis les calculs actuariels (on est une société d'assurances), jusqu'à la génération du courrier, l'archivage, les communications xml avec les institutions et autorités de contrôle, etc.; on est en cours de réécriture d'une v2, réécrite totalement objet, alors que V1 est plutôt procédurale à l'ancienne :-( Faut dire, on débutait, à l'époque...

On fait fort peu de SQL; on utilise plutôt un FindKey ou FindNearest et des boucles Next : c'était infiniment plus rapide (en tout cas il y a dix ans ! peut-être maintenant la différence de performance s'est-elle atténuée ?)

Mon inquiétude vient de ce que
- d'une part, BDE, on répète que c'est mort depuis des années, et ça finira bien par être le cas. Mais c'est triste, car la solution Delphi/400 sur BDE est vachement rapide et efficace !
- d'autre part, avec la multiplication des exécutables sur nos postes clients, on rencontre depuis des mois des problèmes. Chaque exécutable a évidemment son propre TDatabase vers le 400, plus un vers des tables locales, et - selon les machines et les moments - quand on atteint plus de trois ou quatre exécutables, c'est plantage assuré. Ca doit tenir à la config du BDE plutôt qu'à Delphi/400 proprement dit.

On a beaucoup trop peu de temps à consacrer aux recherches technologiques (la pression métier est énorme pour notre petite équipe); on a essayé une connexion ODBC avec dbExpress; ça marche, mais c'est hyper-lent. Car (c'est triste mais les contingences historiques sont ce qu'elles sont) nos programmes clients sont trop lourds, ils font beaucoup trop de lectures et de mises à jour qui devraient en réalité être faites par le 400 - mais l'équipe étant ce qu'elle est, c'est inévitable... Du coup, l'aspect rapidité de traitement est cruciale, et Delphi/400 via le BDE, c'est ce qu'on a trouvé de mieux jusqu'ici !

D'où deux questions se posent :
- est-ce que certains d'entre vous ont déjà eu ce genre de problème (trop de connexions tuent la connexion :-) ?
- Comment anticiper la vraie mort de BDE tout en restant rapide ?

[Paul TOTH]

ça fait des années que je n'ai pas utilisé un AS/400 mais déjà à l'époque il était en pleine évolution avec TCP/IP, FTP et même PHP.

En FTP j'avais de très bonnes performances et ça me suffisait pour récupérer localement les données qui n'étaient pas mise à jour sous Delphi.

Je pense que aujourd'hui face à cette problématique j'explorerais l'approche WebService PHP sur AS/400...vu que je suis aussi compétent sur PHP que sur Delphi ^^

Je ne sais pas ce qu'est devenu RPG, mais en RPGILE 4 il n'était pas encore possible de faire un programme générique d'accès aux données (ou alors de façon relativement complexe) et impossible d'en faire un serveur IP. J'avais commencé à faire une usine à gaz en FTP j'uploadais les mise à jour dans une table temporaire (QTEMP) et j'invoquais un programme RPG pour mettre à jour la base réelle...mais faire un RPG générique était complexe, et sinon je devais créer un programme de mise à jour par table...un peu lourd, mais ça fonctionnait.

[ShaiLeTroll]

On fait fort peu de SQL; on utilise plutôt un FindKey ou FindNearest et des boucles Next : c'était infiniment plus rapide (en tout cas il y a dix ans ! peut-être maintenant la différence de performance s'est-elle atténuée ?)

En Paradox ou DBase, c'est plus rapide FindKey
En MySQL ou Oracle, le SQL est imbattable surtout si gros volume de données, en réseau, tu ne peux pas te permettre de récupérer une table entière, il faut savoir réduire les flux au maximum

- d'une part, BDE, on répète que c'est mort depuis des années, et ça finira bien par être le cas. Mais c'est triste, car la solution Delphi/400 sur BDE est vachement rapide et efficace !

Faut faire un test de ADO ou DBExpress dessus mais pour comparer, il faut revoir les accès, fini le Open Table, il faut réduire le nombre d'enregistrement récupéré (voir PacketRecord et autre chose du genre, j'avoue ça je n'ai jamais bien maitrisé, j'ignore ce que cela fait côté serveur)
Cela demande de repenser son appli en SQL, comme pour les listings web, souvent paginés pour réduire les flux, c'est le même principe, il faut récupérer un nombre juste d'enregistrement !

le BDE est un zombie très résistant !

- d'autre part, avec la multiplication des exécutables sur nos postes clients, on rencontre depuis des mois des problèmes. Chaque exécutable a évidemment son propre TDatabase vers le 400,
Ca doit tenir à la config du BDE

Configurer le BDE est un art !
Je ne le connais pas du tout appliquer à l'AS400
Tu peux aussi penser en multi-tiers, tes clients se connectent sur un serveur applicatif type DataSnap ou DCOM, c'est lui qui traite les demandes
le serveur applicatif est le seule qui a une connexion sur la DB, tu peux ainsi réduire les IP qui ont accès au serveur, d'un point de vue sécurité, c'est mieux, tu peux aussi mettre en place des caches et autres optimisations classiques dans des applications web de masse (surement l'archi multi-tiers la plus répandue)

Ton serveur peut être en BDE, prévoit juste un code souple pour faciliter dégager le BDE par DBExpress par exemple !
En OO, une bonne encapsulation permet de faire cela mais celle demande une rigueur pénible à vivre pour l'équipe de développement, on peut vite être tenté de biaiser que de respecter l'absolu séparation IHM \ Métier !
Au pire, on finira par avoir des environnements totalement émulés, genre une VM en XP pour faire tourner ton appli BDE sans ennui, je le vois déjà pour des clients qui sont amateurs de Mac mais dont les applis métiers sont majoritaitement sous Win32, un Virtual PC et hop c'est réglé (avec d'autres soucis quand même)

- est-ce que certains d'entre vous ont déjà eu ce genre de problème (trop de connexions tuent la connexion :-) ?

Oui rien qu'avec IB6, lorsque tu achètes que 20 licences clients, tu apprends vite ce genre de problème !
Plus tu as de connexion plus cela coûte au serveur mais aussi pour le trafic réseau !
Bcp de SGBD facture au nombre de serveur\processeur avec plusieurs serveurs répliqués qui répartissent la charge, tu as des architectures DB extrêmement onéreuses pour les très grosses sociétés

- Comment anticiper la vraie mort de BDE tout en restant rapide ?

Trouve une VRAIE bonne solution et tu seras riche !

J'avais commencé à faire une usine à gaz en FTP j'uploadais les mise à jour dans une table temporaire (QTEMP) et j'invoquais un programme RPG pour mettre à jour la base réelle...un peu lourd, mais ça fonctionnait.

Je n'ai pas bossé sur AS400 mais j'ai du y envoyer des données, j'ai eu souvent ce cas de figure un FTP + RCMD à l'époque du bon vieux TNMFTP