Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3756 connectés 

  FORUM HardWare.fr
  Windows & Software

  WinNT, planification AT, lancement .vbs et accès SQL problématique

 
 


Dernière réponse
Sujet : WinNT, planification AT, lancement .vbs et accès SQL problématique
Requin Le problème avec VBScript c'est que la gestion d'erreur est proche de zéro...  Si il y une erreur le script est stoppé sans autre forme de procès, toi tu ne peux quasiment rien faire pour intercepter l'erreur.
 
A peu de chose près la seule chose que tu puisses faire est de lui dire de passer à la ligne suivante en cas d'erreur et d'utiliser l'objet Err pour regarder si une condition d'erreur connue s'est produite.

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
Requin Le problème avec VBScript c'est que la gestion d'erreur est proche de zéro...  Si il y une erreur le script est stoppé sans autre forme de procès, toi tu ne peux quasiment rien faire pour intercepter l'erreur.
 
A peu de chose près la seule chose que tu puisses faire est de lui dire de passer à la ligne suivante en cas d'erreur et d'utiliser l'objet Err pour regarder si une condition d'erreur connue s'est produite.
HumanRAGE putain ce travail de sale :lol:
comme koi y a tjs une solution ;) :lol:
Prems Le "On Error Resume Next" réserve TOUJOURS des surprises ;)
Leg9 Ok merci, le problème est résolu... mais ce n'étais rien de tout ça.
 
En fait UN des scripts s'est lancé sans souci ce w-e.
 
Donc ce n'était pas un pb de droits, pas un pb de service pas démarré, rien de tout ça...
 
En fait, ces gorets dont j'ai repris le code avaient collé un gros "on error resume next" qui camouflait un truc délirant.
 
Dans les scripts se lançant correctement avec moi loggé, mais pas sans personne de loggé, il y avait un type mismatch de folie, un cast de long (clng) qui foirait lamentablement car le cast se faisait sur une chaine du genre "200409 23", l'espace qui tue quoi...
 
J'ai viré le cast, et là une belle erreur SQL m'indiquant qu'il ne peut pas mettre une chaine dans un champs long, normal quoi...
 
MAIS je ne pige toujours pas pourquoi, avec le "on error resume next" ça passait avec moi loggé.
Que ça ne passe jamais, moi loggé ou pas, j'aurais compris.
Mais là...
 
En fait le cas anormal n'était pas quand ça ne s'éxecutait pas, mais quand ça s'éxecutait alors que ça aurait du planter, vous suivez? :D
HumanRAGE

Requin a écrit :

A mon avis ton problème est plutot lié au fait que le compte utilisé pour la planification n'a pas les droits d'accès à l'interpréteur de script.
 
Il devraient se trouver sous :
C:\winnt\system32\cscript.exe
C:\winnt\system32\wscript.exe


les droits sont pour le system, les admins et utilisateurs
AT est en System normalement, mais verifier ne coute pas cher (enfin a mon avis leg a résolu le probleme ou transféré le bébé, c'etait pour hier :/)
Requin

Leg9 a écrit :

Je suis un peu une tanche en VBS, aussi je ne sais pas bien comment récupérer les erreurs sur l'éxecution de :

Code :
  1. Public Function makeRS(sql)
  3. ' Déclaration de 3 variables
  4.     Dim conn
  5.     Dim stmt
  6.     Dim rs
  8. ' Créé une connexion à la base de données et l'ouvre
  9.     Set conn = CreateObject("ADODB.Connection" )
  10.     conn.Open ConnectionString
  12. ' Créé une commande (requête) à la base de donnée
  13.     Set stmt = CreateObject("ADODB.Command" )
  14.     Set stmt.ActiveConnection = conn
  16. ' Constante qui indique que la requète est au format texte
  17.     stmt.CommandType = adCmdText
  19. ' Passe la requête (probablement de type SELECT vu qu'on obtient des données)
  20.     stmt.Commandtext = sql
  22. ' Créé un recordset pour stocker le résultat de la requète
  23.     Set rs = CreateObject("ADODB.Recordset" )
  24. ' Défini les attributs du recordset
  25.     With rs
  26.       .CursorLocation = adUseClient
  27. ' Obtient les données en utilisant l'objet command et la connexion ouverte ci-dessus
  28.       .Open stmt, , adOpenStatic, adLockOptimistic
  29.       Set .ActiveConnection = Nothing
  30.     End With
  31. ' Retourne le recordset comme résultat de la fonction
  32.     Set makeRS = rs
  33. ' Libère la mémoire
  34.     Set stmt = Nothing
  36.   End Function


Argh.. récupérer du code auquel on ne pige rien, pas cool...[:jofission]


 
A mon avis ton problème est plutot lié au fait que le compte utilisé pour la planification n'a pas les droits d'accès à l'interpréteur de script.
 
Il devraient se trouver sous :
C:\winnt\system32\cscript.exe
C:\winnt\system32\wscript.exe
krisix

Leg9 a écrit :

Je ne suis pas un voleur, je ne suis pas un violeur, juste un pauvre petit informaticien voulant coder dans la dignité... [:jofission]


 
:D
 
aLors tu t'en es sorti ?
Pas mon domaine vb, sql...juste un p'tit up au cas où.  :??:

HumanRAGE so what :??:
Leg9 Je ne suis pas un voleur, je ne suis pas un violeur, juste un pauvre petit informaticien voulant coder dans la dignité... [:jofission]
Leg9 Up? Une autre idée quelqu'un? :sweat:
Leg9 Ok merci, je vais voir avec ça.
 
Je vais en profiter pour aller voir sur prog si quelqu'un peut m'aider pour récupérer les erreurs des scripts vbs.
Ca pourrait me donner une idée si les erreurs sont claires.
Kalipok

Leg9 a écrit :


Je suis un peu une tanche en VBS, aussi je ne sais pas bien comment récupérer les erreurs sur l'éxecution de :


Désolé, moi aussi, j'emettais juste une idée  [:neowen]  
 
(d'ailleurs on m'a récemment demandé un coup de main sur un prog VB, j'avais répondu "Boaaaah j'en ai fait il y a qqs années, ça devrait aller :o", puis j'ai lu le code [:fear]. On oublie vite, c'est dingue [:tilleul])
HumanRAGE odbc : gestionnaire odbc dans le panno de config, ou dans les outils sql du menu demarrer
tu devrais trouver un des trucs ki correspond a un handle que tu dois utiliser dans tes scripts ... si tu peux trouver kkun avec des competences bdd/odbc, ca vous prendrait 1h a deux, au lieu de te faire chier a passer des heures et des heures tout seul. je c pas comment marche ta boite, mais je sais que dans mes boites passées, g tjs eut moyen de debloquer kkun pendant une heure ou deux quand c'etait la merde et que j'avais besoin d'une competence specifique pour resoudre un probleme urgent
 
msdtc : installé avec ie4 et ultérieur je crois, processus msdtc.exe dans les taches, "Distributed Transaction Coordinator" dans la liste des services, mais si les requetes passent par un driver odbc non pris en charge par le DTC ('tain mais lol koi) ca loguera que dalle
si ca logue quelque chose, ca se trouve dans %windir%\system32\msdtc\ le fichier c'est msdtc.log, tout connement (il peut etre ailleurs, g pas de cd nt sous la main pour install et verifier :/)
 
ils sont pas cho pour ca, mais l'important c ke ca marche non ? et puis un server en exploit', verrouillé ou sur la mire de login c kif kif ... (comme je disais, c meme mieux quand il est verrouillé, car quand le systeme a mal au cul, ouvrir une session est parfois impossible, alors que la deverrouiller ne pose aucun probleme)
Leg9 Merci de vos réponses... :sweat:
 

Kalipok a écrit :

Il n'y aurait pas moyen de récupérer un log de l'exécution de tes vbs ? Genre récupérer les codes retour de la connexion à la base SQL...  
Cela permettrait au moins de savoir si tu te fais jeter lorsque tu essayes de te connecter à la base (genre un service ADODB qui n’est pas lancé, comme tu le disais), ou si tu te connectes bien mais que les requêtes ne s’exécutent pas (problème de droits liés à l'utilisateur)


Je suis un peu une tanche en VBS, aussi je ne sais pas bien comment récupérer les erreurs sur l'éxecution de :

Code :
  1. Public Function makeRS(sql)
  3.     Dim conn
  4.     Dim stmt
  5.     Dim rs
  7.     Set conn = CreateObject("ADODB.Connection" )
  8.     conn.Open ConnectionString
  10.     Set stmt = CreateObject("ADODB.Command" )
  11.     Set stmt.ActiveConnection = conn
  13.     stmt.CommandType = adCmdText
  15.     stmt.Commandtext = sql
  17.     Set rs = CreateObject("ADODB.Recordset" )
  18.     With rs
  19.       .CursorLocation = adUseClient
  20.       .Open stmt, , adOpenStatic, adLockOptimistic
  21.       Set .ActiveConnection = Nothing
  22.     End With
  23.     Set makeRS = rs
  24.     Set stmt = Nothing
  26.   End Function


Argh.. récupérer du code auquel on ne pige rien, pas cool...[:jofission]
 

HumanRage a écrit :

activer la trace sur le server BD sur les tables concernés par les requetes, ca serait un plus yep


Apparemment c'est fait, mais il n'y aurait rien selon l'admin...
 

HumanRage a écrit :

c'est du NT4 ?
pkoi le server ne pourrait pas avoir une session locale ouverte et verrouillée en exploitation ?  
on peut mettre un autologon, et utiliser un soft pour verrouiler la session aussitot ouverte, ca a de plus l'avantage d'avoir deja une session ouverte au cas ou le server parte en couille, vu le temps d'ouverture de la 1ere session sur un server (2000 ou nt, meme combat) c meme un + pour la maintenance ...


Mouaif, ils m'ont l'air moyen chaud là dessus... :/
 

HumanRage a écrit :


bien verifier les droits odbc sinon, et si le MSDTC est installé, il fait des logs il me semble


Hu? Ca se fait ou ça? C'est quoi? Ca sert à quoi? :D
HumanRAGE

Leg9 a écrit :

Hu?
 
Le gestionnaire des taches n'est accessible que si je suis loggé, or là ça marche. Il me faudrait savoir pourquoi ça ne marche justement quand je n'ai pas grand moyen de savoir ce qui se passe...
 
A moins que je n'ai pas compris ta remarque... :D


http://www.sysinternals.com/ntw2k/ [...] cexp.shtml
"process explorer" c un freeware ki permet de voir la liste des taches sur un server a distance, donc de comparer quand kkun est loggué ou pas ... c a peu pres sur que ton probleme vient d'un service ou couche jscript pas chargé, mais cette couche n'a pas necessairement son propre processus
 
en tant que tech d'exploitation, je te conseille la session ouverte et verrouillée automatiquement, avec comme argument le gain de temps en cas de maintenance ... c ptet pas tres classieux, mais bon au moisn ca marchera
 
par contre, sous nt4 il n'y a pas de point d'entree public accessible pour locker l'os, je v voir si jpeux trouver un soft qui peut le faire (eventuellement avec les sources :D)
http://www.freevbcode.com/ShowCode.asp?ID=5262     a tester
bizarre lockworkstation n'existe pas sous nt dans la user32.dll il me semble, faudrait tester :/
 
y a bcp de sites qui en parlent donc ca doit marcher pour NT4 aussi :)
HumanRAGE

Kalipok a écrit :

Il n'y aurait pas moyen de récupérer un log de l'exécution de tes vbs ? Genre récupérer les codes retour de la connexion à la base SQL...  
Cela permettrait au moins de savoir si tu te fais jeter lorsque tu essayes de te connecter à la base (genre un service ADODB qui n’est pas lancé, comme tu le disais), ou si tu te connectes bien mais que les requêtes ne s’exécutent pas (problème de droits liés à l'utilisateur)
 

activer la trace sur le server BD sur les tables concernés par les requetes, ca serait un plus yep
HumanRAGE c'est du NT4 ?
pkoi le server ne pourrait pas avoir une session locale ouverte et verrouillée en exploitation ?  
on peut mettre un autologon, et utiliser un soft pour verrouiler la session aussitot ouverte, ca a de plus l'avantage d'avoir deja une session ouverte au cas ou le server parte en couille, vu le temps d'ouverture de la 1ere session sur un server (2000 ou nt, meme combat) c meme un + pour la maintenance ...
 
bien verifier les droits odbc sinon, et si le MSDTC est installé, il fait des logs il me semble
Kalipok Il n'y aurait pas moyen de récupérer un log de l'exécution de tes vbs ? Genre récupérer les codes retour de la connexion à la base SQL...  
Cela permettrait au moins de savoir si tu te fais jeter lorsque tu essayes de te connecter à la base (genre un service ADODB qui n’est pas lancé, comme tu le disais), ou si tu te connectes bien mais que les requêtes ne s’exécutent pas (problème de droits liés à l'utilisateur)
L'admin windows n'est pas non plus mon domaine...
Bon courage :sweat:
Toxin Post de soutien, moi je suis largué :o
Prems Pas de doc fournie avec la BDD ?
Leg9

Prems a écrit :

Si tu vois que dans ce gestionnaire des tâches, le service qui va bien est lancé par toi-même, tu as la réponse.


Pas con.
Mais je ne sais pas du tout ce qui est nécessaire au bon fonctionnement d'un lancement de requète SQL via un .vbs. :/
Prems Si tu vois que dans ce gestionnaire des tâches, le service qui va bien est lancé par toi-même, tu as la réponse.
Leg9

Prems a écrit :

Si tu le vois dans le gestionnaire des tâches, tu peux voir par qui il a été lancé.


Hu?
 
Le gestionnaire des taches n'est accessible que si je suis loggé, or là ça marche. Il me faudrait savoir pourquoi ça ne marche justement quand je n'ai pas grand moyen de savoir ce qui se passe...
 
A moins que je n'ai pas compris ta remarque... :D
Prems

Leg9 a écrit :

J'imagine, mais les scripts contenant la string de connexion restent les mêmes lancés par AT avec moi loggé ou sans moi... c'est là que je ne pige pas...
 
A moins qu'un service nécessaire genre ADODB ne soit pas lancé sans utilisateur loggé... j'y pige rien! :cry:


 
Si tu le vois dans le gestionnaire des tâches, tu peux voir par qui il a été lancé.
Xamoth le firewall. :o
 
 

Spoiler :

bon courage :o
Leg9 J'imagine, mais les scripts contenant la string de connexion restent les mêmes lancés par AT avec moi loggé ou sans moi... c'est là que je ne pige pas...
 
A moins qu'un service nécessaire genre ADODB ne soit pas lancé sans utilisateur loggé... j'y pige rien! :cry:
Prems D'après ce que tu dis c'est plutôt un pb de droits d'accès à la base, non ?
Leg9 Si tu veux étant donné que ce souci est remonté au moment de la recette, il faudrait idéalement que j'arrive lundi avec une solution sûre, et pas un "on sait jamais" :D
 
En gros le projet en est déjà à 3 fois le temps vendu par un commercial passablement indélicat, il faut que je sauve les meubles, et là ce genre d'annerie me met vraiment des batons dans les roues. :D
Prems On ne sait jamais.
Leg9

Prems a écrit :

C'est dans les options d'IE qu'on trouve des restrictions d'éxécutions de scripts.


Yep mais IE n'a pas grand chose à voir avec une tache lancée par AT en tache de fond sans aucun utilisateur loggé? Si? :??:
Prems C'est dans les options d'IE qu'on trouve des restrictions d'éxécutions de scripts.
Leg9 Autre chose apparement At est indépendant du "planificateur de tâches" graphique de WinNT, puisque les commandes planifiées dans At n'y apparaissent pas...  
 
Clarification à ce sujet anyone? :)
Leg9

Prems a écrit :

Message de pure solidarité. ;)
 
Vérifie les droits d'éxécutions des scripts d'IE, ou si tu as un antivirus qui traîne...


S'lut Prems :D
Pourquoi IE? :??:
Prems Message de pure solidarité. ;)
 
Vérifie les droits d'éxécutions des scripts d'IE, ou si tu as un antivirus qui traîne...
Leg9 Salut,
 
J'ai un _gros_ souci au boulot, j'ai un projet à "rattraper", je prend donc totalement le train en marche et suis plus ou moins obligé de me conformer à ce qui était en train d'être développé.
 
La problématique : que le planificateur de taches AT tournant sur un serveur NT lance régulièrement des .cmd de récupération de fichier de données, puis lance derrière des .vbs d'insertion dans une base tournant sous SQL server.
 
J'ai réussi à faire tout ça, mais...
 
Actuellement : AT est rempli correctement avec les taches adéquates, les commandes et les scripts se lancent correctement.
 
Si je suis loggé, pas de soucis : les .cmd lançant un wget récupèrent bien les fichiers, les .vbs insérent bien dans la base et effacent ensuite les fichiers. Zéro souci.
 
En revanche, si on laisse tourner le planificateur sans que personne ne soit loggé (ce qui sera évidemment le cas en exploitation), les commandes et les scripts sont bien exécutés, les .cmd récupèrent bien les fichiers, mais les .vbs n'insèrent pas dans la base.
Par contre ils sont bien lancés puisqu'ils effacent les fichiers.
Argh...
 
Je soupçonne un souci de droit, ou de path, ou autre truc du genre, et donc d'administration Windows plus que de programmation VB. Ceci étant je peux totalement me gourrer, j'avoue que ça dépase mon domaine de compétences.
 
Etant vraiment dans le flou total (en plus d'une merde noire [:chacal_one333]), toute aide constructive serait grandement appréciée. :D

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)