Discussion :

[anissbenben]

Bonjour,
j'ai déveleppé une application de gestion (developpée avec DELPHI7) en utilisant firebird pour communiquer avec la base de données.
Les premiers temps , il n'y avait aucun soucis, mais , apprès une année d'utilisation , l'application commence à prendre BEAUCOUP DE TEMPS pour se lancer (environ une demi-heure) pendant l'utilisation de l'application , tous marche normal

Merci pour votre aide.

[Ph. B.]

Bonjour,

Il faudrait savoir ce que fait l'application au démarrage et avec quels composants elle fonctionne...
Si par exemple, elle ouvre des tables (composant TTable ou un leur équivalent), elle va donc adresser plusieurs requêtes au moteur de bases de données, requêtes qui vont nécessiter du temps avant d'être toute traitée... Ces temps vont donc s'accroitre au fur et à mesure que le volume de données va augmenter.

A mon avis, il s'agit surtout d'un problème initial de conception de l'application et surtout de la manière dont elle va accéder aux données :

1. en totalité, dès le démarrage
2. à la demande et sur des ensembles pertinents (avec des conditions de filtre, etc)

[anissbenben]

L'application en elle meme communique avec une base de données via interbase et firebird ! est-ce que le fait que la base de données devient grande cause ce genres de soucis ! ? et comment fait firebird avec interbase pour charger la base de donnée au départ ? est-ce une siple conexion et requettes ou tout un chagement de la base ?

[Ph. B.]

L'application en elle meme communique avec une base de données via interbase et firebird !

Vous mélangez plusieurs concepts. Interbase et Firebird sont des moteurs de base de données. Firebird est né d'un fork d'Interbase 6.
Votre application consulte et alimente votre base de données via un de ces 2 moteurs...
Ma question est : Comment s'adresse-t-elle à 1 de ces moteurs ? Avec quels composants (TTable, TIbTable, TQuery, TIbQuery, etc) ?

est-ce que le fait que la base de données devient grande cause ce genres de soucis ! ?

Firebird ou Interbase peuvent gérer des bases de données de plusieurs Giga octets sans souci. L'accès à une base de données dépend de la manière dont vous accédez à ces données :

1. en ouvrant toutes les tables au démarrage (très très mauvaise solution) en utilisant des composants TTable ou apparentés,
2. ponctuellement en fonction des demandes et en se limitant aux données pertinentes (bonne solution) en utilisant des composants TQuery ou apparentés.

et comment fait firebird avec interbase pour charger la base de donnée au départ ?

Les moteurs de base de données ont leur propre mécanisme pour gérer les données et fournir celles qui sont demandées (je n'ai pas dit toutes les données) le plus rapidement possible; normal, c'est leur travail. Par contre, une application se doit de ne demander que l'ensemble de données minimal dont elle a besoin à un instant "t".

est-ce une siple conexion et requettes ou tout un chagement de la base ?

Tout dépend de comment a été écrite votre application...
Il y a globalement 2 moyens d'actions pour faire disparaitre ces lenteurs:
a) côté base de données :

poser des index pertinents sur les tables de la base de données,

b) côté application :

éviter d'utiliser les composants TTable ou apparentés et pire de les ouvrir tous dès le démarrage de l'application,
utiliser les composants TQuery ou apparentés en écrivant des requêtes SQL où sera banni autant que possible les select * from au profit de select colonne1[, colloneI] from

[anissbenben]

merci pour votre réponse qui m'a fait comprendre beaucoup de choses, effectivement, j'ai des tas de query et de dataset et pleins d'autre aussi qui sont ouvert au démarrage mais je n'utilise aucun ttable ! voilà tout, je vais donc essayé d'"optimiser" si puis-je dire !
merci encore une fois ! je rends la réponse dès que ça sera fait

[SergioMaster]

Avez vous aussi pensé à la 'santé' de votre base de données :
Transactions non fermées etc ....

un Backup de votre base Firebird permettra déjà de vider la 'poubelle'
un Restore recalculera les indexs et recompactera la base
un Gfix avant ces opérations , permettrait de situer les problèmes !
Attention , au vu des temps de récation de votre programme , il serait bon de faire un restore 'test' dans une nouvelle BDD plutôt que d'écraser l'ancienne tout de suite .

Vous indiquez des Query , mais Ph.B. pensait certainement aussi au type de composants BDE,IBxxxxx,ADOxxxx,DBExpress etc ... qui ne gèrent pas du tout les transactions de la même manière (d'où la question).

a noter : j'ai une grosse application D3+BDE+Firebird+20postes qui a maintenant + de 10ans , jamais je n'ai eu de lenteur de démarrage (max 1mn) sauf problème réseau bien sur

[ShaiLeTroll]

BEAUCOUP DE TEMPS pour se lancer (environ une demi-heure) pendant l'utilisation de l'application

C'est totalement inconcevable comme temps, je me serais inquiété dès la minute passée !

Tu devrais regarder les principes de Lazy Loading et de Lazy Initialisation !
C'est l'art et la manière de retarder au plus tard que possible l'allocation d'une ressource, cela utilise souvent Singleton et Factory\Multiton

Cela vaut aussi pour la DB !

J'ajouterais le Prepared ou Prepate(), cela dépend des moteurs, utile pour une requête fréquemment lancé mais seule les valeurs dans les critères de recherche change (voir ParamByName...) comme par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM client WHERE nom = :param

En préparant à l'avance avec un prepare explicite, cette requête sera 10 fois plus rapide qu'un prepare implicite

[edam]

+, surement qu'on tu ouvre une requette, il y a plein qui sont liée maitre/esclave soit par liaison directe des composant soit dans afterscroll, aussi je te déconseil aussi d'utilisé lookup, mieux intégrer tout dans une seul requette avec jointure, et aussi il y les champs calculer si il contient des résultat de requette, même si une requette avec firebird il envoit une seul ligne au début, mais comme tu dis qu'il plantte pandant 1/2 heur, sa veux dire que tu récupére quelque part toute une tableou plus avec des dizéne de chmps calculer en arriére,

[akli_agha]

Essaies donc de mettre des points d'arrêt pour savoir à quel niveau le programme plante. Comme dit plus haut, plusieurs raison peuvent affecter les délai de ton appli. Une fois que t'as détecté la procédure ou l'instruction qui retarde l’exécution, tu la corrigera. Ne dit-on pas qu'un problème connu est à moitié résolu !

Bon courage.