Discussion :

[WebPac]

Bonjour tout le monde,
lorsqu'on ouvre une requête avec un TSQLQuery et que la base de donnée met un quart d'heure pour ouvrir la requête, l'application reste figée pendant ce quart d'heure.

La solution est de faire l'ouverture de cette requête dans un Thread, ainsi on peut continuer à travailler. Mais on ne peut pas kicker l'ouverture de la requête tant qu'elle n'est pas terminée (j'ai essayé tout ce que j'ai pu trouver et rien n'a marché). A cause de ça, la suppression du composant à la fermeture de l'application attend la fin de l'ouverture de la requête. Ce qui est embêtant si on doit attendre 15 minutes le temps que la requête s'ouvre.

Une solution serrait de mettre un TimeOut avant d'ouvrir la requête, ainsi si par exemple au bout d'une minute la requête ne s'est pas encore ouverte, on arrête l'ouverture de la requête.
J'ai cherché dans les propriétés du TSQLQuery ainsi que dans le TSQLConnection mais je n'ai pas trouvé d'allusion à un TimeOut.

Je viens ici demander si quelqu'un a une solution pour implémenter un TimeOut.
Merci.

[tatareau]

un TimeOut peut être une sorte de chrono dans un Thread différent de ta requête.le thread Timeout est lancé avant ta requete et à la fin d'un temps précis test un boolean. Ce boolean aura changé d'état (vrai par exemple) après le succés de ta requête.
Bon code

[WebPac]

Merci pour ton aide, mais je connais déjà tout cela. Mais quand on a une requête qui met 15 minutes à s'ouvrir, même en mettant un minuteur pour arrêter le traitement, on peut continuer le travail dans le thread principal mais la requête qui tente de s'ouvrir est inaccessible dans le thread principal, on ne peut pas l'arrêter. C'est ce problème dont je parle.

[tatareau]

YES, j'avais pas compris . En effet c'est l'ouverture de requête qui est bloquant..Il me semble que c'est du côté du SGBD qu'il faut chercher. En effet c'est là où le blocage se "passe", à l'ordonnencement des requêtes. Comme on dit, contact ton administrateur de bases.
C'est seulement une idée
Bon Code

[WebPac]

YES, j'avais pas compris . En effet c'est l'ouverture de requête qui est bloquant..Il me semble que c'est du côté du SGBD qu'il faut chercher. En effet c'est là où le blocage se "passe", à l'ordonnencement des requêtes. Comme on dit, contact ton administrateur de bases.
C'est seulement une idée
Bon Code

Ouais mais non, car la base de donnée est celle du client, elle peut être en SQL Serveur, Oracle, Firebird, Access, Informix, autre via ODBC et j'en oublie.
De plus faire une application qui travaille sur des connexions à des bdd et qui n'arrive pas à se fermer, on ne peut pas demander à l'utilisateur de contacter son administrateur de base de donnée pour nous déconnecter, ça fait pas très pro.
C'est vraiment un point bloquant, surtout quand on commence à tapper sur des gros volumes.

[Rayek]

Est il posible de voir la requete?
Car je trouve que 15mn c'est un peu trop pour une requete.

Sinon n'est il pas possible de découper le gestion de la requete en plusieurs étapes (faire une partie de la requete puis une autre partie etc ...) et entre chaque étape vérifier qu'il n'y a pas une demande d'arret du traitement.

[WebPac]

Est il posible de voir la requete?
Car je trouve que 15mn c'est un peu trop pour une requete.

Sinon n'est il pas possible de découper le gestion de la requete en plusieurs étapes (faire une partie de la requete puis une autre partie etc ...) et entre chaque étape vérifier qu'il n'y a pas une demande d'arret du traitement.

Je peux te montrer la requête, c'est un SELECT DISTINCT avec 8 tables et 7 jointures, le fait qu'il y ait le DISTINCT oblige Firebird (c'était la base incréminée sur le coup) de devoir trier les enregistrements, bug de Firebird ou pas, il créait plus de 5Go de fichiers temporaires.

Je ne désire pas réparer le problème pour un moment ponctuel mais dans un cas général car l'utilisateur peut créer une requête qui mette du temps à s'ouvrir ne le sachant pas à l'avance avant de tester la requête et ne désire pas devoir attendre 15 minutes pour pouvoir fermer l'application car il a voulu tester une requête.

Je ne peux pas non plus découper en plusieurs parties car, je ne sais pas à l'avance si la requête mettra du temps ou non et interpréter une requête en fonction de ce que demande l'utilisateur n'est pas envisageable.

[Rayek]

Peux tu remplacer ton Disctinct pas une condition Exists ?

Le distinct bouffe à mort du temps et il n'est peut être pas nécessaires dans ta requete.

Sinon essaie avec une clause Group by à la place du distinct, ca revient au même.

[WebPac]

Peu importe le cas précis qui crée ce problème, je veux que l'application puisse gérer ce genre de problème.
Je ne sais pas tout ce que l'utilisateur peut faire et je ne vais pas dire à l'utilisateur "non il ne faut pas faire de DISTINCT, le temps d'ouverture est trop long".

Il faut que l'application puisse fonctionner convenablement même lorsque l'utilisateur fait une requête qui met trop de temps à s'ouvrir.

[Rayek]

La, je vois pas comment faire pour ton problème.

[WebPac]

C'est fort dommage parce que je me dis qu'il n'y a pas vraiment de solution.
Et chaque fois qu'un utilisateur crééra une requête impossible, il faudra qu'il kicke l'application pour la fermer, ça fait tout sauf pro.

[Rayek]

Avec Ado tu aurais pu faire une barre de progression pour faire patienter l'utilisateur

[WebPac]

Est-ce qu'avec Ado on peut arrêter l'ouverture en cours ?
Avec dbExpress, j'ai mis aussi une barre de progression mais que lors du parcours des enregistrements, tu parles pour le parcours ou pour l'ouverture ?

[Rayek]

Est-ce qu'avec Ado on peut arrêter l'ouverture en cours ?

Hélas, il n'y pas de possibilités d'arreter en cours de route. A un moment j'ai cru que CancelBatch aurait pu faire l'affaire mais non, c'est pas ca

Avec dbExpress, j'ai mis aussi une barre de progression mais que lors du parcours des enregistrements, tu parles pour le parcours ou pour l'ouverture ?

Je te parle bien pendant que la requete fait son travail (pendant tes 15mn ^^)
J'utilise cette technique quand j'ai des requetes un peu longue, avec une progressBar + un gif animé, ca évite de croire que le prog est planté

Les composants Ado peuvent être mis asynchrone et après il y a 3 événements qui permettent de traiter une progressBar (OnWorkBegin,OnWork et OnWorkEnd).
Il faut que je fasse une QR sur ça d'ailleurs.

[WebPac]

Merci pour l'information, je compte un jour utiliser les composants ADO.

[tatareau]

J'ai eu à traiter des requêtes de plusieurs heures. La solution à été chaque fois de passer soit par des procédures stockées écrites en PL/SQL por Oracle, soit passer par des scripts en Perl. Pour vraiment de très gros volumes (millions d'enregistrements) on a réduit des traitements de 10-20 heurs à l'odre de la minute.
A ce niveau là , le choix de l'outil de dév. est stratégique, cf au chef de projet!!
Bon Code

[WebPac]

Salut tatareau, quand les temps de traitement étaient de 10-20H, c'était en utilisant des requêtes SQL classiques ?
Les scripts Perl sont exécutables depuis une autre application ? Que faisaient-ils qui fasse que les temps soient si réduits ?
Le PL/SQL est-il un standard ou réservé à Oracle ?

En gros, j'aimerais bien que tu m'en dises plus.

[tatareau]

Au départ les requêtes SQL était codées en dures dans le code Delphi. On les à deplacées en proc stock sur le SGBD. Pour le PL/SQL c'est le langage réservé à Oracle. C'est un langage simple (type basique) développé pour écrire des traitements sur la base et incorporé naturellemnt de la requête SQL, on peut gérer les enregistrements, boucles, conditions, les exceptions . L'avantage c'est lqu'il travaille côté serveur base, et l'on peut préparer la base de donnée à traiter au mieux les requêtes (pour les détails côté Oracle type volume des blocs d'enregistrement à traiter, je m'en remetais à l'administrateur et moi j'écrivais le pgm en PL/SQL).
Les scripts Perl était lancé par un script bash ou un cron.
Les scripts Perl ont permis surtout des envois de mail en très grand nombres (plusieurs milliers) grâce à des modules d'accés à la Oracle (il existe des modules DBI pour d'autres bases) d'interroger les tables pour les adresses e-mails etc et cela c'est avéré plus rapide que Delphi. Je cois qu'il y a ici une FAQ Perl pour cela.
Ce que j'ai retenu c'est que la rapidité venait que nous travaillons au niveau du serveur et du SGDB (proc stock), avec sans doute des modules plus "natifs" que les couches successsives imposé par les objets Delphi.
Bon code

[WebPac]

Merci pour les précisions, je comprends bien la limite de Delphi qui encapsule trop de couches, mais je ne crois pas trop que je puisse changer tout cela pour l'instant, je me vois mal dire aux utilisateurs que les traitements importants vont maintenant ce faire via un batch, cela fait pas assez "pro". Sans parler du fait que des gens pourraient modifier les scripts.

Pour le fait d'inclure les procédures dans le SGBD, c'est aussi une bonne idée mais je travaille sur plusieurs SGBD en même temps, un servant de source et un autre servant de destination, avec en source n'importe quel SGBD et en destination cela peut être Oracle, SQL Serveur, MySQL ou Firebird.
Donc arriver à mettre ces procédures en place de façon générique va être un peu difficile à priori.

Mais je garde ces idées sous le coude, je pense qu'elles serviront un jour ou l'autre.

[tatareau]

Content d'avoir rendu service. En revanche ce sont des méthodes vraiment pro, ces méthodes ont été utlisés pour la facturation dans un grand groupe de téléphonie/ Internet qui sponsorise l'OM...Il est vrai que l'on avait tout loisir d'agir sur nos serveurs ce qui n'est peut être pas le cas présentement et seule les devs avec les droits KiVonBien peuvent toucher les scripts du serveur!! et encore sur les serveur de dev pas ceux de production!!! Ce que je veux dire c'est que les scripts peuvent être très pros...
Bon Code à tous