DominoArea.org [Archive]

Bonjour,

Je suis embêté en ce moment avec mes serveur Notes/SQL.
Une erreur revient régulièrement et je n'arrive pas savoir d'où cela provient :/

Mes agents vont régulièrement consulter des bases SQL.
J'utilise le LSDO pour exécuter des requêtes simple genre "select champ1 from table where champ2='xxxx'"
Certaines plus complexes mais rien de vraiment compliqué, loin de la même :/
Et je me retrouve avec une erreur :

Code : Tout sélectionner

[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionWrite (WrapperWrite()).(select  xxx from xxx where CHAMP ='xxx' and DONNE='xxx') - LS:DO- ODBC could not complete the requested operation.

Code : Tout sélectionner

[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (WrapperRead()).(Select TOP 1 xxx from xxx WHERE xx=(SELECT xxx FROM xxx WHERE xxx='xxx') AND xxx<>'xxx') - LS:DO- ODBC could not complete the requested operation.

Je ne vois pas d'où peut venir ce ConnectionRead (WrapperRead()) & ConnectionWrite (WrapperWrite())

Avez-vous déjà été confronté à ces erreurs ?
Et si oui, comment les avez-vous résolues ?

Merci de votre aide.

Vincent

Pour savoir si ta requête est bonne je te conseil de l'exécuter directement à partir d'Excel. C'est un test que je fais régulièrement avant de le faire via Notes.

Ensuite, reste à savoir si les classes LSDO sont bien instanciées avant l'envoi de la requête et, dernière chose, vérifie les droits d'exécution de la requête sur le serveur SQL

Mes requêtes sont correctes, l'objet est bien instancié et les droits sont ok...c'est bien pour cela que je ne comprend pas ce qui se passe...J'espère que ce n'est pas a cause d'un nombre trop important de demande d'exécution de requêtes au serveur SQL :/

Lorsque tu parles de requête qui fonctionne, tu l'as vérifié directement à partir d'une console SQL ou comme je t'avais dit, via Excel?

Parfois, les requêtes sont bonnes lorsqu'on les exécutes directement sur une console SQL, mais il arrive qu'elles plantes lorsqu'on les exécutes via ODBC et Excel est un bon test.

En effet c'est plus sûr de vérifier si Excel le fait bien, ça veut dire que ça fonctionnera (enfin ... )

cdlt

Alain

Je viens de tester avec Excel (bien que je ne doute pas du résultat) et ça fonctionne donc cela ne vient pas des requêtes (si c'était des requêtes select qui posaient problème, j'aurais changé de métiers direct pour devenir berger dans les Pyrénées ^^).
Mais je testerais maintenant par excel/ODBC. J'y avais jamais pensé ^^

Pour exposer un peu plus, il doit y avoir plusieurs centaines de connexions par jour (voir plus) sur le site et toutes sont susceptibles d'exécuter telle ou telle requête. Hors si c'était les requêtes, j'aurais des centaines de log mais ce n'est pas le cas :/

C'est pour cela que j'en viens à me demander s'il me perd pas les pédales vu le nombre important de connexions au serveur SQL qu'il peut faire

Merci,
Vincent

Les logs qui remontent viennent toujours d'un même utilisateur (service, hub, sous réseau ???)

cdlt

Alain

PS: C'est cool berger dans les pyrénées

La base de données, c'est SQL Server j'imagine?

Tu as essayé de faire une procédure stockée et de l'appeler via la requête SQL?

Remplacer SQL Server par DB2 ou Oracle, y'a pas mieux

Pour les bases, oui, c'est SQL Server et remplacer par DB2 ou Oracle, je crois que ça va pas être possible ^^

Pour les ProcStock, on essaye de remplacer au fur et à mesure les requêtes présentes dans le code par des ProcStock pour améliorer la sécurité mais c'est galère et long :/

Enfin, j'ai un agent planifié qui fait énormément de connexion SQL pour effectuer différentes vérification. Et généralement, quand il y a de gros soucis sur les serveurs, c'est pas très longtemps après l'exécution de cette agent...j'vais le désactiver pendant quelques jours et voir ce que cela donne...

Merci,
Vincent

Sinon, pour éviter d'avoir a faire plusieurs connexions, centralise les requêtes SQL sous 1 seule connexion. Ca pourrait alléger les délais dans les requêtes.

Oui je suis d'accord mais malheureusement, il y a l'historique en place qui fait que ça serait difficile à modifier...donc on attend la prochaine version du site, qui est en cours de dev (par mes soins..je crains le pire ^^), qui améliore les process/perf/etc...mais en attendant, je dois faire avec :/

Là, je ne peut plus faire grand chose sauf te souhaiter bonne chance!

Bah vendredi, j'ai désactivé un agent planifié qui je soupçonne être à l'origine du problème. J'ai prié tout le WE pour que les serveurs ne tombent pas et les puissances supérieures ont dû m'entendre, les serveurs sont toujours la et sans trop de soucis

Enfin, c'est toujours sous surveillance...