L'accès au fichier à partir de l'objet COM Excel échoue lors de l'exécution du service NT sur Vista

Question

Nous utilisons des objets COM pour accéder aux feuilles de calcul Excel dans un service NT (via l'hôte Windows Scripting). Avant Vista, cela fonctionnait à merveille, mais à partir de Vista, nous recevons cette erreur:

Microsoft Office Excel ne peut pas accéder au fichier 'c: \ myfiles \ test.xls'. Il existe plusieurs raisons possibles:

• Le nom de fichier ou le chemin n'existe pas.
• Le fichier est utilisé par un autre programme.
• Le classeur que vous essayez d'enregistrer porte le même nom qu'un classeur actuellement ouvert.

J'ai essayé de modifier les paramètres d'ouverture de session du service NT pour utiliser mon propre compte, un compte administrateur et un système local. J'ai examiné la politique de sécurité locale et n'ai rien trouvé. J'ai passé des jours à chercher dans Microsoft KB en vain.

Si le script est exécuté à partir d'une application de console, cela fonctionne correctement. Le fichier s'ouvre et est traité sans problème. L'erreur se produit uniquement lorsqu'elle est exécutée dans le contexte d'un service. Si le service est exécuté sur Windows XP ou Server 2003 SP1, il fonctionne également correctement. Ce n'est que sur Vista qu'il échoue (et nous avons maintenant des rapports d'échec dans Server 2003 SP2)!

Le code, pour ce qu'il vaut la peine est extrêmement simple:

dim xl_app 
Set xl_app = CreateObject("Excel.Application") 
xl_app.Workbooks.Open mypath,0,1 

Je soupçonne que cette personne pourrait être victime du même problème: http://bytes.com/forum/thread819740.html

Answer 1

que quelques autres questions:

• Quelle version d'Excel utilisez-vous?
• Avez-vous essayé d'exécuter le service avec des privilèges élevés?

Answer 2

J'ai "un peu" résolu ce problème. Si vous utilisez "dcomcnfg" pour changer le compte pour lancer l'application Excel sur un compte utilisateur ou "utilisateur interactif", l'Excel lancé à partir du service démarre dans ce compte et peut maintenant accéder au système de fichiers.

Le problème est qu'il s'agit d'un paramètre global. Si vous utilisez: * "cet utilisateur": alors Excel ouvre TOUJOURS avec cet utilisateur ET ouvre toujours avec aucune interface utilisateur dans la session 0, même pour l'utilisation interactive d'Excel. IE est toujours invisible. * "Utilisateur interactif": Maintenant Excel se lance toujours dans le compte utilisateur interactif qui ne fonctionnera pas pour un service qui se lancera au démarrage avec AUCUN utilisateur interactif.

Il doit y avoir un réglage de sécurité à ce sujet. J'espère que les autres ont d'autres idées.