Veuillez également ajouter une fonction
myquery << status
qui renvoie le statut comme
- créé
- en cours d'exécution
-fini
-échoué
☐ nouvelle fonctionnalité intéressante
☑ pourrait aider de nombreux utilisateurs !
☐ supprime un « bug »
☐ agréable à avoir
☐ personne n'en a besoin
Qu'est-ce qui a inspiré cette demande de liste de souhaits ?
La commande
New SQL Query()
est très utile car il permet à l'utilisateur d'exécuter la requête en arrière-plan. Pendant l'exécution de la requête, l'utilisateur peut continuer à travailler dans Jmp. Très efficace 
La commande
Execute SQL()
est très utile pour le débogage car il envoie le message d'erreur SQL au journal.
Il semble que la commande New SQL Query n'ait pas la possibilité d'enregistrer le message d'erreur ( catch Sql Query error ) et que la commande perform SQL n'ait pas la possibilité d'exécuter la requête en arrière-plan
Quelle est l’amélioration que vous souhaiteriez voir ?
Si tel est le cas, veuillez permettre d'exécuter au moins un des codes suivants :
myquery = New SQL Query();
myquery << run;
myquery << get error message;
ou
Execute SQL (... , run background )
Pourquoi cette idée est-elle importante ?
Avec la nouvelle fonctionnalité, l'utilisateur a la possibilité
- faire autre chose pendant l'exécution de la requête SQL
- pour trouver des fautes de frappe dans le code SQL
plus de vœux soumis par 
Concernant
myquery << status
Je viens d'apprendre de @jthi que View/Running Queries répertorie toutes les requêtes qui s'exécutent en arrière-plan : État de la requête
Ce serait donc bien si ces informations étaient également accessibles via JSL...
Le bénéfice:
Un utilisateur peut exécuter des requêtes SQL en arrière-plan et le code peut attendre la fin de la requête.
En attendant, l'utilisateur pouvait continuer à travailler...
L'idée jusqu'à présent :
Récupérez le message d'erreur SQL pour déboguer la requête lorsqu'elle échoue.
Un nouveau problème, beaucoup plus grave, a été évoqué aujourd'hui lors de la réunion des utilisateurs DACH 2025 ( @Georg )
un cas où la requête de base de données est interrompue avant d'être terminée :
Correction d'un bug JMP : l'erreur ODBC n'était pas transmise à l'utilisateur.
Comme certaines données sont récupérées et que JMP ne signale aucune erreur, l'utilisateur n'a pas l'occasion de s'en apercevoir.