836688_fr-FR

liliconcom

Correction du bug JMP : l'erreur ODBC n'est pas transmise à l'utilisateur

Qu'est-ce qui a inspiré cette demande de liste de souhaits ? Nous avons rencontré des problèmes avec des ensembles de données incomplets, c'est-à-dire qu'à partir de différentes exécutions de requêtes, nous avons obtenu un nombre différent de lignes de la base de données en utilisant « nouvelle requête SQL » avec ODBC-DSN. Cela se produit parce que la connexion de requête s'exécute en attente de délai lors de la récupération des données et que JMP n'a pas transmis l'erreur et n'a pas informé l'utilisateur de cela.

Quelle amélioration souhaiteriez-vous voir ? J'ai besoin que JMP informe l'utilisateur de l'erreur ODBC, que l'utilisateur sait qu'il y a un problème et qu'il peut le résoudre.

Pourquoi cette idée est-elle importante ? Parce qu'avec ce comportement, l'utilisateur perd la confiance que l'acquisition de données par JMP fonctionne correctement et que l'ensemble de données est incomplet. Il s'agit simplement d'une correction de bug.

Pour contourner ce problème, on m'a dit de configurer le délai d'attente dans les paramètres ODBC, mais cela ne fonctionnera que lorsque l'utilisateur sera au courant du problème. Sans JMP pour l'informer du problème, il n'en sera probablement pas conscient. Même s'il est au courant du problème, la requête suivante peut prendre plus de temps et il peut à nouveau rencontrer le même problème. Il doit donc extraire les données plusieurs fois pour savoir s'il y a un problème. C'est quelque chose que je n'aime pas.

Accès aux donnéesRé: Correction du bug JMP : l'erreur ODBC n'est pas transmise à l'utilisateur

Il serait très utile d’obtenir des informations sur des ensembles de données incomplets.

Ré: Correction du bug JMP : l'erreur ODBC n'est pas transmise à l'utilisateur

Pouvez-vous également partager ici comment configurer le délai d'attente dans les paramètres ODBC ?

Ré: Correction du bug JMP : l'erreur ODBC n'est pas transmise à l'utilisateur

Cher @DatabaseWhimp ,

il existe différentes manières, et cela dépend de votre système/pilote.

Sous Windows, vous pouvez configurer le paramètre dans le DSN (application Windows ODBC-Database-Administrator 64 bits), puis accéder au DSN utilisateur et modifier les paramètres de connexion.

Voir la capture d'écran, cela fonctionnera uniquement pour le DSN utilisateur, pas pour le DSN système (que nous avons dans notre cas, notre service informatique a déployé le DSN en tant que DSN système).

Une autre façon est d'ajouter une chaîne à la fin du SQL que vous envoyez à la base de données dans « Custom SQL() », avec les paramètres de connexion, comme ici dans cette sélection :

select now() from dual()
CONTEXT('QUERYTIMEOUT' = '900')

Re: Correction du bug JMP : erreur ODBC non transmise à l'utilisateur - Statut modifié en : Reconnu

Merci d'avoir partagé votre demande ! Nous apprécions votre contribution et l'examinerons rapidement. Nous vous tiendrons au courant de toute mise à jour.

Re : Correction d’un bug JMP : L’erreur ODBC n’est pas transmise à l’utilisateur

Mise à jour avec JMP 19.0 :

• Nous constatons toujours le problème
• Problème : nous obtenons des ensembles de données incomplets (par exemple, 2000 lignes sur 21 469 lignes).
• Pour une nouvelle table, l'utilisateur reçoit une indication (le nom de la table est « Importation partielle de ... »).
• Lorsqu'une requête est lancée par le script « Mise à jour à partir de la base de données », aucune indication n'est fournie.
• Je considère toujours cela comme un bug grave (et non comme une fonctionnalité manquante que je pourrais demander dans une liste de souhaits).

Mes questions :

• Quand verrai-je une amélioration ?
• Que signifie « Accusé de réception » ? Quel impact ce statut a-t-il sur le comportement réel du logiciel JMP ?