Erreur 70 n'apparaissant que sur certains comptes utilisateurs

Question

Bonjour, 

Voilà, j'ai un petit problème avec une appli écrite en VB6 qui doit tourner sur des postes équipés de Windows 7.
Le problème se manifeste sur un poste en particulier 
(le seul, elle tourne très bien sur les autres postes pour tous les comptes) :

Lorsque je la lance sur ce poste sous compte administrateur, tout se passe bien, pas de problème, comme sur les autres postes

Mais dès que je la lance sous un compte utilisateur lambda, j'ai ce message : 
'Erreur 70, Permission refusée'

Il me faut pouvoir lancer cette appli sur ce poste qui pose problème depuis un compte utilisateur lambda (sans droits admin), 
et je ne peux pas modifier le code de cette application.

J'ai déjà essayé :
-Par dcomcnfg.exe, aucun résultat
-En mettant la séurité des applis la plus permissive possible, aucun résultat
-En mettant l'exécution sous mode de compatibilité XP, aucun résultat 
 
N'y aurait-il pas une bidouille à faire dans le paramétrage en l'ordi pour faire
en sorte que cette erreur ne se manifeste plus ?

N'est-il pas possible de désactiver totalement le contrôle de sécurité des applications, vu que c'est lui qui pose problème ?

ucfoutu · Answer

Bonjour,
N'y aurait-il pas une bidouille à faire dans le paramétrage en l'ordi pour faire
en sorte que cette erreur ne se manifeste plus ? 
Aucune "bidouille" sans l'intervention de l'un des administrateurs. Sinon, ce ne serait plus de la sécurité
 N'est-il pas possible de désactiver totalement le contrôle de sécurité des applications, vu que c'est lui qui pose problème ?
Bien évidemment, mais là encore : intervention de l'un des administrateurs indispensable.
Et c'est heureux, non ?

NHenry · Answer

Tu as cette erreur en faisant quelle action ?
As-tu essayé de contrôler l'erreur en utilisant ON ERROR ?

gerbito · Answer

Bonjour,

et merci pour ta réponse.

Malheureusement, l'exécutable de l'appli ne peut être modifié...

Par contre, je sais quel code est exécuté et pose problème, mais je ne peux le modifier. C'est la sécurité paramétrée sur ce poste qui met le foutoir lors d'une copie de fichier depuis un dossier réseau effectuée au lancement de l'appli. Voici ce qui pose problème :

            Dim fs                                Set fs = CreateObject("Scripting.FileSystemObject")                fs.CopyFile "[Dossier réseau]\mabase.mdb", App.Path & "\mabase.mdb"


Le problème ne vient de toutes façons pas du code exécuté (qui est correct), mais bien de la sécurité. Quand j'essaie, sur ce poste et sous compte utilisateur, de faire la copie manuellement par l'explorateur Windows, j'ai aussi l'erreur 70 "Permission refusée".

NHenry · Answer

Tu ne pourras pas apsser outre la sécurité du poste.
Donc, utilises ON ERROR pour gérer l'erreur.

gerbito · Answer

Non... 

Car je ne peux pas modifier ce code. 
Y compris pour y rajouter ON ERROR. Je ne peux pas gérer l'erreur dans le code, il me faut trouver un moyen de faire en sorte que ce code, que je ne peux modifier, fonctionne sur ce poste dont la sécurité pose problème de la même façon que sur les autres postes.

Il doit être possible de court-circuiter la sécurité sur ce poste, vu que l'appli fonctionne très bien sur les autres postes. 

C'est juste sur un poste en particulier que se produit l'erreur 70.

ucfoutu · Answer

Une autre fois, donc :
- s'il s'agit d'une protection de la machine cliente, tu ne pourras rien faire depuis ton application (me relire)
J'ajoute ceci, par ailleurs :
- certaines machines (dont la mienne, où j'ai carrément inhibé VBS ****) ne laisseraient tout simplement pas passer FSO  ! Je ne le dirais jamais assez fort : E V I T E R ce faux-ami    FSO. VB6 offre mieux et moins lourdaud que FSO ! FileCopy existe sous VB6 seul, quand-même !!!! Pourquoi utiliser FSO ??????
- qu'est donc le chemin de App.Path ? Si dossier ou répertoire protégé, ma foi ... tu peux toujours "courir" pour tenter de "bidouiller" ......

 De nombreux responsables (dont moi-même) ont délibérément inhibé l'exécution de scripts, dont les scripts VBS. Nous avons NOS raisons, que tu comprennes ou non ces raisons. Et dans un tel contexte, aucun de ces scripts ne pourra être exécuté.
- 
 
________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.

gerbito · Answer

Je sais très bien que je ne peux rien faire depuis l'appli, étant donné que je ne peux pas modifier le code de cette appli (me relire aussi... ;) ), je ne peux que voir le code qui est exécuté.

Et ce code, malheureusement, ne comporte pas de gestion d'erreur mais fait appel au FSO. Alors je sais, c'est très moche... 

Mais c'est comme ça et cette appli doit fonctionner sur le poste ou elle bloque à cause de la sécurité du poste en question. Parce qu'elle fonctionne très bien sur les autres postes et doit fonctionner aussi sur celui-là.

Si je pouvais régler le problème par le code, il serait réglé depuis longtemps, mais la seule façon de le régler c'est d'influer sur la config du poste. Cela dit, étant donné que l'appli tourne sur tous les autres postes mais pas sur ce poste X, la logique amène à conclure que c'est bien le poste X qui a un problème et pas l'appli.

App.Path, c'est une propriété donnant le chemin de l'exécutable de l'appli, qui se trouve dans un dossier dédié sur "C:\Program Files", que ce soit sur le poste où elle bloque où sur les autres postes où elle se lance sans souci.

Maintenant, pour ce qui est des "responsables" qui font du blocage délibéré, la solution est simple : petit courriel à qui de droit pour signaler que le travail attendu ne peut être réalisé à cause du "responsable" en question, le problème se débloque très très très vite...

Mais là, ce n'est plus le problème, le problème c'est de faire fonctionner cette appli sur ce poste rebelle.

ucfoutu · Answer

Désolé, mais je ne vois dans ce cas pas d'autre solution que celle d'intervention "en tant qu'administrateur" du responsable de la machine concernée. Et cet aspect-là ne relève absolument pas du développement sous VB6 (vocation de ce forum).
Quant à :
App.Path, c'est une propriété donnant le chemin de l'exécutable de l'appli, qui se trouve dans un dossier dédié sur "C:\Program Files"
Il se trouve qu'il s'agit-là d'un dossier nativement protégé à partir de Windows 7. Et seul un administrateur, agissant "en tant qu'administrateur", peut lever, s'il y consent, cette protection. C'est à lui (et à lui seul) qu'il appartient de décider de l'opportunité ou non de lever cette protection-là.
Rien d'autre à dire à ce sujet.

Erreur 70 n'apparaissant que sur certains comptes utilisateurs

8 réponses

Votre réponse

Discussions similaires