Discussion :

[alakauf]

Bonjour,
J'ai un ami qui a écrit une appli sous Delphi 4, accédant à une base MySQL. Cette appli utilise des TTable et des TQuery. Pour pouvoir l'utiliser en mode déporté (l'appli sur son portable, la base reste sur un PC chez lui) quand il est en déplacement, il m'a demandé d'essayer d'optimiser les accès. En effet actuellement l'accès base est bien trop lente (probablement à cause des TTable) et entraine de ce fait des timeout.

Sauf que mes connaissances en Delphi sont très limitées, et que j'ai du mal à savoir quoi faire. Il m'a parlé de voir à quoi peut bien servir (et si cela aide) les TUpdateSQL. J'ai fait une tentative à l'aide de l'exemple fourni, mais j'ai un souci, avec une erreur "la requête n'est pas possédée par la base" (la requête est dans le module correspondant à la fenêtre que j'ai essayé de modifié, et la base est dans un module spécifique) lorsque j'appelle le ApplyUpdate.

Aussi j'aurais besoin, aussi bien de connaître les meilleures approches pour optimiser les accès base, sachant que chaque fenêtre (il y en a une quinzaine) fait de l'affichage, de l'ajout, de la suppression, et de la modification). Et, si le TUpdateSQL est intéressant dans mon cas, comment résoudre le problème de l'erreur (j'espère que ce n'est pas en déplaçant la query dans son module, car vu le nombre de TTable cela va être pénible).

Merci d'avance pour vos réponses.

[ShaiLeTroll]

le BDE utilisant le Driver ODBC pour accéder à MySQL, ce n'est pas le plus rapide, tu aurais les mêmes soucis de performance avec ADO d'ailleurs ... mais en Delphi 4, tu n'as pas pas le choix, c'est BDE, faudrait changer de Delphi, pour avoir des lib plus performantes comme MyDAC de Devart (D6 ou D7 au minimum, ensuite tenter d'aller plus loin en version, c'est plus compliqué)

Supprime TOUS les TTables, passe tout en TQuery pour les SELECT et les UPDATE\INSERT
oublie le Edit\Append\Post au possible, n'utilise que du SQL, c'est une façon de programmer totalement différente ...

Ton SELECT sera surement en Lecture Seule, donc tu peux le lier avec un TUpdateSQL qui te permet d'avoir des SQL pour gérer justement les UPDATE et INSERT en tapant toi même les requêtes au lieu de laisser Delphi le faire maladroitement ... pour ma part, c'est un truc vicieux que j'évite ou sinon il faut bien le documenter pour savoir que ces requêtes sont présentes ... en fait il remplace le Edit\Append\Delete justement ... je préfère avoir explicitiment mes requêtes dans le code que cachées dans les méandres de l'IDE et de la DFM ... c'est un gros travail qui nécessite une bonne connaissance du relationnel et des requêtes paramétrèes ... pour pousser plus loin, tu pourrais aussi préparer les requêtes les plus fréquentes, cela devrait améliorer leur performance aussi ! Bon Courage ! J'espère que c'est payé !


Sinon, je ne comprends pas très bien, c'est ton ami qui a écrit l'appli, donc c'est lui qui la connait le mieux, et c'est à toi qui n'y connais rien à qui il demande de l'optimiser, c'est pas très judicieux ?

[Franck SORIANO]

En général, le plus gros problème des appli Db écrites en Delphi c'est avant tout le nombre de requêtes exécutées.
Ca devient d'autant plus problématique lorsque la base de données est distante et que tu as un ping important.

Malheureusement, réduire le nombre de requêtes exécutées nécessite généralement une réécriture profonde de l'application :
- Il faut faire la chasse au Data-aware (ne pas utiliser les composants TDbXXXX de Delphi), car ses derniers contiennent beaucoup trop d'automatismes qui déclenche des requêtes à tout bout de champs de façon non maîtrisée.
- Mettre en place des caches pour ne pas réinterroger des tables qui n'ont pas bougés (par exemple toutes les tables systèmes, contenu des combos, paramétrages...)
- Ne pas faire n petites requêtes lorsqu'on peut tout faire dans une seule...

Enfin, il faut choisir des API performantes pour accéder à la base de données (malheureusement avec MySQL et Delphi 4, tu n'as pas beaucoup de choix...)