Discussion :

[Oluha]

Salut,

J'ai un soucis avec un package qui s’exécute correctement dans Visual Studio mais qui plante quand j'essaye de l’exécuter avec SQL Agent.

A priori c'est la connexion avec mon fichier Excel qui merdouille.

Executed as user: SERVEUR05\SYSTEM. ...n 9.00.5000.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 08:45:00 Error: 2013-01-12 08:45:01.28 Code: 0xC0202009 Source: EXTRACT_GRACE_COPY Connection manager "Gestionnaire de connexions Excel" Description: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040154. An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered". End Error Error: 2013-01-12 08:45:01.29 Code: 0xC020801C Source: Injecter Kid Excel Destination [22] Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Gestionnaire de connexions Excel" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed. The package execution fa... The step failed.

J'ai vu sur l'aide Microsoft que ça pouvait venir d'un problème de droit du SQL Agent mais j'avoue ne rien comprendre à leur explication

http://support.microsoft.com/kb/933835/fr

Pour résoudre ce problème, vous devez modifier les autorisations du répertoire Temp du compte de démarrage du Service de l'Agent SQL Server. Accorder l'autorisation en lecture et l'autorisation d'écriture sur le compte proxy de l'Agent de SQL Server 2005 pour ce répertoire.

Il est où ce répertoire ? Et quel est le nom exact du compte ?

Bref, si quelqu'un pouvoir m'aider...

Merci !

PS : j'ai lu que ça pouvait être un problème de conflit 64/32 bits mais j'ai bien mis la propriété "run64bitruntime" à false dans mon package...

[d.joubert]

Oui, ça ressemble plus à un problème 32/64bits

Il est stocké où ton package et où est-ce que tu as coché le run64 ?

[Oluha]

Alors j'ai enregistré le package dans "Magasin de package SSIS" et sinon c'est dans Projet > Propriétés > Débogage que j'ai coché la case.

J'ai trouvé une autre page qui semble donner la solution à mon problème mais je ne comprends pas où faire les modifications qu'ils indiquent

http://blogs.msdn.com/b/dataaccesste...eshooting.aspx

1. When the package fails as a job, we can provide two resolutions:


A) Modify the job step of the failing package, change the "Type" to Opearting System (cmdExec) and edit the command line manually to run it through the 32-BIT DTExec.exe. You need to prefix the full path of 32-BIT DTExec.exe before the command (Typically, under default installation, the path would be (C:\Program Files (x86)\Microsoft Sql Server\DTS\Binn\DTExec.exe).

Je suis allé dans les propriétés de l'étape de mon job, mais je ne vois pas où modifier le chemin qu'ils indiquent...

[d.joubert]

Dans ton job, va sur l'étape où tu lances le package.
Dans l'onglet 'Executions Options', coche 'use 32 bits runtime'

[Oluha]

Je n'ai pas cette case dans sql server 2005

Effectivement, si je vais sur mon SQL server local qui est en 2012, j'ai bien cette option

Mais en cochant la case depuis mon SQL server local sur le serveur distant, ça ne fonctionne pas, évidemment...

[d.joubert]

Donc ce cas là, dans ton job, dans l'étape où tu exécutes ton package, tu ne dois pas mettre 'SQL Server Integration Services' dans le type mais 'Operating System (cmdExec)'
Et dans la commande, tu écris le chemin complet vers le dtexec en 32 bits

[Oluha]

Ah oui, je dois être bigleuse, j'avais pas vu que le fameux "type" dont parlait mon lien était là !

Maintenant ça fonctionne, merci beaucoup !

[yenamare]

Bonjour,

J'ai exactement le même problème que Oluha mais je ne comprends pas, mon serveur est en 32 bits. Je ne peux donc pas appliquer la solution proposée.
Si quelqu'un a une idée ....
Merci beaucoup