Discussion :

[micoudev]

Bonjour,

Sur une forme, j'ai une table "Query".
Je charge les instructions SQL par programme, puis je l'active dans un contrôle "try/except"
J'intercepte bien toutes sortes d'erreur, mais quand je définit, dans le code de ma requete, un lecteur amovible et qu'il n'y a rien dans celui-ci, j'obtiens cette erreur, que je n'arrive pas à contrôler :

There is not disk in the drive. Please insert a disk into drive \Device\Harddisk3\DR15

Normal, puis le message :

Le projet SFMLS.exe a provoqué une classe d'exception EBDEngineError avec le message "Le lecteur n'est pas prêt Fichier: m:\Voitures.dbf" Processus stoppé. Utilisez pas à pas etc...

Et ensuite seulement, j'arrive dans mon except.

Cette erreur correspond au code erreur suivant ;

DbiErr_OsDriveNotReady (11061 $2B35)

Mais impossible de l'intercepter

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
begin
        try
          If Query1.Active then Query1.Active := False;
          Query1.SQL.Clear;
          Query1.SQL.LoadFromFile(WCheminDatabase + WSQL_Name);
          Query1.Active := True;
          Membres.Active := True;
          MbrWork.Active := True;
          MbrWork.BatchMove(Query1, batCopy);
          Query1.Active := False;
              // Ca plante juste après l'instruction ci-dessus
          Membres.Active := False;
          MbrWork.Active := True;
          Label3.Caption := IntToStr(MbrWork.RecordCount);
        except
          on E: Exception do
          begin
            MbrWork.Active:= False;  // efface le résultat de la précédente requête
            ShowMessage('Au moins une erreur empêche l''exécution de la requête'
            + #13 + #13 + ' --> ' + E.Message + #13 + #13
            + '   Corriger et relancer');
          end;
        end;

[ShaiLeTroll]

C'est une notification du Déboggueur !
C'est une option, tu peux cocher la case "ignorer exception", ainsi tu ne l'auras plus la prochaine fois, et dans les options du débuggueur, tu peux choisir les exceptions à ignorer !
Ce ne concerne que le déboggueur, cela n'a pas d'impact sur la gestion des exceptions par ton programme

Lance le programme sans Delphi, as-tu TON ShowMessage ?

[micoudev]

C'est une notification du Déboggueur !
C'est une option, tu peux cocher la case "ignorer exception", ainsi tu ne l'auras plus la prochaine fois, et dans les options du débuggueur, tu peux choisir les exceptions à ignorer !
Ce ne concerne que le déboggueur, cela n'a pas d'impact sur la gestion des exceptions par ton programme

J'avais déjà essayé de ce coté, mais le message d'erreur (le 1er) s'affiche quand même.

Lance le programme sans Delphi, as-tu TON ShowMessage ?

Oui, le showmessage arrive bien dans tous les cas de figure.
Le fait de décocher "Arret sur exceptions Delphi" ne fait que supprimer le deuxième message.

Note : Le premier apparaît toujours deux fois. Je valide une 1ere fois(bouton "Continue"), et il se réaffiche tel quel une deuxième fois, ensuite, j'arrive sur mon ShowMessage.

[ShaiLeTroll]

Le Message en Anglais "There is not disk ..." s'affiche toujours même sans Debug ?
Peut-être faire la démarche inverse, au lieu de laisser l'exception, utilise un GetDriveType (ou fonction similaire) pour détecter le type de disque et voir si il accessible AVANT d'utiliser le BDE !

[micoudev]

Le Message en Anglais "There is not disk ..." s'affiche toujours même sans Debug ?

Oui, il s'affiche systématiquement. Pour moi, c'est très clair
Le problème est qu'il n'y a pas que moi qui utilise ce programme. De plus, les commandes SQL sont affichées/Modifiées par l'utilisateur, dans un memo, et mon programme les recopie dans un fichier pour être lu (dans le code ci-dessous)

Code :

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

 Query1.SQL.LoadFromFile(WCheminDatabase + WSQL_Name);

Il peut donc (à l'insu de son plein gré ) entrer une valeur erronée. Et il ne m'est pas facile d'analyser d'abord toute la syntaxe avant l'exécution. Et comme la boîte de dialogue propose les boutons "Cancel" "Retry" et "Continue", cela peut perturber un non-inité, d'autant que le message se réaffiche systématiquement une seconde fois.

Peut-être faire la démarche inverse, au lieu de laisser l'exception, utilise un GetDriveType (ou fonction similaire) pour détecter le type de disque et voir si il accessible AVANT d'utiliser le BDE !

Pour cela, il faut que je puisse isoler à priori tous les mots-clé de la requête

[ShaiLeTroll]

Ah, la requête ce n'est pas ton programme qui l'a construit !
Tu ne peux pas guider l'interface utilisateur ?

Perso, je ne laisse pas un utilisateur tapé du SQL !
Rien que pour des obligations légales, il y a de données qui ne peuvent pas être modifiés ou supprimées (compta, médical, contrôle d'accès...)

J'ai souvent vu des outils d'import générique configurable (colonne, calcul avant et après import, jointure, tri ...)
Souvent l'outil est un peu complexe, c'est donc en interne que l'on configure et que l'on facture !
Si il y a besoin d'un import très spécifique au métier, on ajoute un écran de configuration dédié à l'import ! idem, on facture mais encore plus !

Rien n'empêche de faire un DELETE FROM ... dans le fichier pointé WSQL_Name, Active certe fera une erreur de curseur mais le DELETE aura été executé !
J'ai vu des concurrents peu scrupuleux qui utilisait ce genre de faille comme modifier un fichier SQL contenant un script pour pourrir d'autres logiciels ou alors supprimer l'alias BDE pour empêcher l'appli de démarrer !
J'espère que seul un utilisateur admin a de tel "pouvoir" !

Que contient ton SQL, est un truc genre SELECT * FROM "m:\Voitures.dbf" ?
Tu indique dans ton message que l'erreur se produit après Query1.Active := false en L10, j'aurais plutôt dit
lors du Query1.Active := true en L6 ! C'est étrange non ?
Ou alors, c'est durant le BatchMove mais dans ce cas "m:\Voitures.dbf" est utilisé par MbrWork ?

Ah le BDE, une belle invention mais qui est aujourd'hui un vrai boulet accroché au pied de Delphi !

[micoudev]

Ah, la requête ce n'est pas ton programme qui l'a construit !
Tu ne peux pas guider l'interface utilisateur ?

J'ai créé plusieurs modèles de cdes SQL, que l'utilisateur peut ouvrir et charger dans le mémo.

Petite explication :
Il s'agit d'un programme qui recense tous les membres d'un club de voitures anciennes. L'objectif de ces commandes SQL est de permettre à l'utilisateur de générer un fichier de travail, du genre "quels sont les membres qui possèdent tel type de voiture", ou bien qui habite dans tel ou tel departement, à des fins de mailing, par ex.

Il existe donc un modèle SQL, dans lequel il y a 2 ou 3 codes "type de voiture", par ex

Code :

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

1
2
3
4
5
...WHERE   (Voitures.V_MKLE = 3)
   OR  (Voitures.V_MKLE = 4)
   OR  (Voitures.V_MKLE = 8)
   OR  (Voitures.V_MKLE = 13).
...

L'utilisateur n'a donc qu'à modifier ce ou ces codes pour obtenir ce qu'il souhaite.
Une fois les cdes saisies (modifiées) dans le memo, elles sont recopiées dans un fichier temporaire. C'est à partir de ce fichier que sont chargées les cdes dans le Query qui va, lui, créer le fichier de travail "Mbrwork.dbf".
Bien entendu, un petit malin peut s'amuser à entrer autre chose, j'en suis bien conscient.

Perso, je ne laisse pas un utilisateur tapé du SQL !
Rien que pour des obligations légales, il y a de données qui ne peuvent pas être modifiés ou supprimées (compta, médical, contrôle d'accès...)

J'ai souvent vu des outils d'import générique configurable (colonne, calcul avant et après import, jointure, tri ...)
Souvent l'outil est un peu complexe, c'est donc en interne que l'on configure et que l'on facture !
Si il y a besoin d'un import très spécifique au métier, on ajoute un écran de configuration dédié à l'import ! idem, on facture mais encore plus !

Rien n'empêche de faire un DELETE FROM ... dans le fichier pointé WSQL_Name, Active certe fera une erreur de curseur mais le DELETE aura été executé !
J'ai vu des concurrents peu scrupuleux qui utilisait ce genre de faille comme modifier un fichier SQL contenant un script pour pourrir d'autres logiciels ou alors supprimer l'alias BDE pour empêcher l'appli de démarrer !
J'espère que seul un utilisateur admin a de tel "pouvoir" !

Je suis entièrement d'accord avec toi. Ici, tous les fichiers (sauf le fichier de travail et le fichier des cdes SQL, sont en readonly, y compris le database. C'est un programme en lecture seule. Je suis le seul à avoir la version avec l'accès complet (ce serait un peu le bazard si chacun pouvait modifier dans son coin . J'espère ainsi avoir limité les risques. De plus, ce ne serait pas une catastrophe, car tous les membres possèdent les mêmes fichiers. C'est à partir des miens que les leurs sont mis à jour régulièrement.

Que contient ton SQL, est un truc genre SELECT * FROM "m:\Voitures.dbf" ?

Voici un ex

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT Voitures.V_AKLE, Voitures.V_MKLE, Voitures.VANNEE, Modeles.MMODELE, Membres.ANOM, Membres.ASTATUS
FROM "Voitures.DBF" Voitures
   INNER JOIN "Modeles.DBF" Modeles
   ON  (Voitures.V_MKLE = Modeles.M_MKLE)  
   INNER JOIN "Membres.DBF" Membres
   ON  (Voitures.V_AKLE = Membres.A_AKLE)  
WHERE   (Voitures.V_MKLE = 3)
   OR  (Voitures.V_MKLE = 4)
   OR  (Voitures.V_MKLE = 8)
   OR  (Voitures.V_MKLE = 13)
ORDER BY Voitures.V_MKLE, Voitures.VANNEE, Voitures.V_AKLE

Tu indique dans ton message que l'erreur se produit après Query1.Active := false en L10, j'aurais plutôt dit
lors du Query1.Active := true en L6 ! C'est étrange non ?

Hum ! Bien vu et erreur pour moi, je n'ai pas mis le commentaire au bon endroit. C'est bien après le Query.Active := True que ça plante !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
      begin
        try
          If Query1.Active then Query1.Active := False;
          Query1.SQL.Clear;
          Query1.SQL.LoadFromFile(WCheminDatabase + WSQL_Name);
          Query1.Active := True;  // <-- Plante après cette instruction
          Membres.Active := True;
          MbrWork.Active := True;
          MbrWork.BatchMove(Query1, batCopy);
          Query1.Active := False;
          Membres.Active := False;
          MbrWork.Active := True;
          Label3.Caption := IntToStr(MbrWork.RecordCount);
        except
          on E: Exception do
          begin
            MbrWork.Active:= False;  // efface le résultat de la précédente requête
            ShowMessage('Au moins une erreur empêche l''exécution de la requête'
            + #13 + #13 + ' --> ' + E.Message + #13 + #13
            + '   Corriger et relancer');
          end;
        end;

Ou alors, c'est durant le BatchMove mais dans ce cas "m:\Voitures.dbf" est utilisé par MbrWork ?

Ah le BDE, une belle invention mais qui est aujourd'hui un vrai boulet accroché au pied de Delphi !

N'empêche ça m'agace de ne pouvoir contrôler ce cas de figure. J'ai essayé un tas de trucs, mais rien ne change. En tapant ce code ereeur, on trouve rien sur internet, a part une liste des codes erreur.