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 ), toute aide constructive serait grandement appréciée.

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
Pourquoi IE?

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?

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?

On ne sait jamais.

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"
 
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'après ce que tu dis c'est plutôt un pb de droits d'accès à la base, non ?

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!

le firewall.
 
 

 
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...

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.

Pas de doc fournie avec la BDD ?

Post de soutien, moi je suis largué

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

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

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

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 )
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

Merci de vos réponses...
 

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

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

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

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

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

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)

Désolé, moi aussi, j'emettais juste une idée    
 
(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 ", puis j'ai lu le code . On oublie vite, c'est dingue )

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.

Up? Une autre idée quelqu'un?

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

so what

 

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

 
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 )

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?

Le "On Error Resume Next" réserve TOUJOURS des surprises

putain ce travail de sale
comme koi y a tjs une solution

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.