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

WinNT, planification AT, lancement .vbs et accès SQL problématique - Windows & Software

Marsh Posté le 25-09-2004 à 14:15:18    

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


Message édité par Leg9 le 25-09-2004 à 14:17:24
Reply

Marsh Posté le 25-09-2004 à 14:15:18   

Reply

Marsh Posté le 25-09-2004 à 14:17:15    

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


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:18:05    

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? :??:

Reply

Marsh Posté le 25-09-2004 à 14:19:33    

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


Message édité par Leg9 le 25-09-2004 à 14:19:47
Reply

Marsh Posté le 25-09-2004 à 14:19:48    

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


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:20:48    

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? :??:

Reply

Marsh Posté le 25-09-2004 à 14:21:45    

On ne sait jamais.


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:25:01    

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


Message édité par Leg9 le 25-09-2004 à 14:32:11
Reply

Marsh Posté le 25-09-2004 à 14:26:37    

D'après ce que tu dis c'est plutôt un pb de droits d'accès à la base, non ?


Message édité par Prems le 25-09-2004 à 14:26:48

---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:29:30    

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:

Reply

Marsh Posté le 25-09-2004 à 14:29:30   

Reply

Marsh Posté le 25-09-2004 à 14:30:58    

le firewall. :o
 
 

Spoiler :

bon courage :o

Reply

Marsh Posté le 25-09-2004 à 14:31:12    

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


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:33:40    

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

Reply

Marsh Posté le 25-09-2004 à 14:36:25    

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.


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 14:52:46    

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

Reply

Marsh Posté le 25-09-2004 à 14:59:21    

Pas de doc fournie avec la BDD ?


---------------
Ratures - Cuisine
Reply

Marsh Posté le 25-09-2004 à 15:38:21    

Post de soutien, moi je suis largué :o


---------------
"If you can walk away from a landing, it's a good landing. If you use the airplane the next day, it's an outstanding landing." - Chuck Yeager. | Chaîne YT | Photos
Reply

Marsh Posté le 25-09-2004 à 16:10:09    

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:

Reply

Marsh Posté le 25-09-2004 à 17:11:05    

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


Message édité par HumanRAGE le 25-09-2004 à 17:11:51

---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 25-09-2004 à 17:16:54    

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


---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 25-09-2004 à 17:29:22    

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


Message édité par HumanRAGE le 25-09-2004 à 17:40:21

---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 25-09-2004 à 20:39:50    

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)
  2.     Dim conn
  3.     Dim stmt
  4.     Dim rs
  5.     Set conn = CreateObject("ADODB.Connection" )
  6.     conn.Open ConnectionString
  7.     Set stmt = CreateObject("ADODB.Command" )
  8.     Set stmt.ActiveConnection = conn
  9.     stmt.CommandType = adCmdText
  10.     stmt.Commandtext = sql
  11.     Set rs = CreateObject("ADODB.Recordset" )
  12.     With rs
  13.       .CursorLocation = adUseClient
  14.       .Open stmt, , adOpenStatic, adLockOptimistic
  15.       Set .ActiveConnection = Nothing
  16.     End With
  17.     Set makeRS = rs
  18.     Set stmt = Nothing
  19.   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


Message édité par Leg9 le 25-09-2004 à 20:40:11
Reply

Marsh Posté le 25-09-2004 à 20:53:41    

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)


Message édité par HumanRAGE le 25-09-2004 à 20:58:16

---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 25-09-2004 à 22:46:45    

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


Message édité par Kalipok le 25-09-2004 à 22:47:03
Reply

Marsh Posté le 26-09-2004 à 14:32:28    

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.

Reply

Marsh Posté le 26-09-2004 à 19:42:02    

Up? Une autre idée quelqu'un? :sweat:

Reply

Marsh Posté le 26-09-2004 à 21:38:35    

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

Reply

Marsh Posté le 27-09-2004 à 23:09:07    

so what :??:


---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 28-09-2004 à 13:23:52    

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ù.  :??:


---------------
Eklektikzik -  PSN:Ser_Kris
Reply

Marsh Posté le 28-09-2004 à 13:39:53    

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


Message édité par Requin le 28-09-2004 à 13:45:08
Reply

Marsh Posté le 28-09-2004 à 18:22:54    

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


---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 28-09-2004 à 21:19:50    

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


Message édité par Leg9 le 28-09-2004 à 21:20:09
Reply

Marsh Posté le 28-09-2004 à 22:35:34    

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


---------------
Ratures - Cuisine
Reply

Marsh Posté le 29-09-2004 à 01:28:12    

putain ce travail de sale :lol:
comme koi y a tjs une solution ;) :lol:


---------------
When I give food to the poor, they call me a saint. When I ask why the poor have no food, they call me a communist. Helder Camara | Telling your employees they're "family" is the corporate equivalent of saying "I love you" to a sex worker.
Reply

Marsh Posté le 29-09-2004 à 06:29:13    

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.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed