Discussion :

[Marshall06]

Bonjour,

Je ne comprends pas mon problème.

Je déploie un package sur le un serveur 2008 en 64bit. Lorque je le lance à la main, click droit run package cela fonctionne (avec utilisation d'un fichier de conf) mais lorsque j'appelle ce même package dans une proc stock ça ne marche plus.
Ma proc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE PROCEDURE [dbo].[SP_ImportFONCIER]
 
 
AS
 
 
SET NOCOUNT ON
 
 
-- lancement du package
 
 
DECLARE @chaine   varchar(2048)
 
 
SELECT @chaine='DTEXEC /DTS "\File System\monJob" /SERVER "." /CONF "maCOnf.dtsConfig"  /CHECKPOINTING OFF  /REPORTING V '
 
EXEC master..xp_cmdshell @chaine
 
RETURN @@Error
 
 
GO

Voilà l'erreur que j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

   Description: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.InvalidOperationException: The 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine.

cela vient d'un script VB que j'ai dans mon package qui lit le fichier excel d'entrée. Le problème est pourquoi ça marche quand je le lance à la main et pas quand je l'appelle depuis une procedure stockée.

Le but étant de lancer le job quand l'utilisateur clique sur "importer excel" depuis l'application .NET

Un grand merci à celui qui me sort de là

[romuald.coutaud]

En effet :

• Dans le premier cas (lancement "à la main") le lot s'exécute avec le DTEXCEUI.exe qui est en 32bit
• Dans le second cas, le lot est lancé depuis la procédure stockée qui contient une commande qui fait appel au DTEXEC.exe qui est en 64bit

Donc, le problème vient du fait que fournisseur OLEDB Jet.4 ne fonctionne qu'en version 32Bit.

Pour plus d'info l'article de l'aide en ligne est assez fournie
http://msdn.microsoft.com/fr-fr/library/ms141766.aspx
Extrait :

Lorsque vous utilisez l'Utilitaire d'exécution de package (dtexecui.exe) sur un ordinateur 64 bits pour développer et tester des commandes, n'oubliez pas que cet outil 32 bits exécute les packages en mode 32 bits. Avant de déployer ou de planifier ces commandes sur un serveur de production, vous devez utiliser la version 64 bits de l'utilitaire dtexec pour les tester en mode 64 bits.

Donc soit tu fait tourner ton lot avec le DTEXEC.exe version 32bit (il est présent même sur les machines 64bit) là encore extrait de l'article MSDN :

Par défaut, un ordinateur 64 bits qui dispose à la fois des versions 64 bits et 32 bits d'une invite de commandes Integration Services doit pouvoir exécuter la version 32 bits. La version 32 bits s'exécute parce que son chemin d'accès au répertoire apparaît dans la variable d'environnement PATH avant le chemin d'accès au répertoire de la version 64 bits. (En général, le chemin d'accès au répertoire 32 bits est <lecteur>:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn, tandis que le chemin d'accès au répertoire 64 bits est <lecteur>:\Program Files\Microsoft SQL Server\100\DTS\Binn.)

Soit tu fais en sorte d'utiliser un fournisseur qui permet d'utiliser Excel en 64bit dans ton package voir ce post et ceux relié sur le même sujet du très bon blog Doubert : http://dougbert.com/blog/post/Excel-...e-by-SSIS.aspx

[Marshall06]

Oui j'ai vu que ça pouvait venir de là.

je suis passé par un Job que ma procédure stockée va lancer, et là ça marche ...

C'est peut être pas très propre mais là ça marche

Merci

[scharly3]

A mon goût un sp_start_job est loin d'être moins "propre" qu'un EXEC master..xp_cmdshell

Après pourquoi lancer le job depuis la Procédure stocké ? Et ne pas tout configurer depuis les jobs ?

• Step 1 : Lancer procédure Stocké
• Step 2 : Lancer Package
• Step 3 ...

??

[Marshall06]

Le job doit être lancer depuis une application en .NET

Le moyen le plus rapide de le faire fonctionner c'est en utilisant une proc stock.

Je suis preneur d'une meilleur idée pour faire ça.

[scharly3]

Le job doit être lancer depuis une application en .NET

Ok j'ai rien dit