Blog

Una operazione che ogni tanto mi trovo a fare, e per far questo utilizzo gli Integration Services di SQL server (SSIS per gli amici), che per potenza e versatilità mi permettono di realizzare l'operazione con pochi click, tramite un workflow grafico.

L'altro giorno, però, ho avuto un problema. Ho operato come sempre, eppure l'importazione falliva di continuo. Con molto disappunto, ho iniziato ad investigare sulla cosa. Ho pensato di avere dei lock sul file excel, poi ho pensato che ci fosse qualcosa di poco standard nel file che avevo ricevuto, ed ho provato a risalvare i file in Excel 2003. Ma niente. Ho provato a riavviare il computer, poi anche SQL Server. Niente falliva di continuo.

Alla fine, dopo diverso tempo che ci provavo, sono andato a vedere il log dell'operazione. Cosa che avrei dovuto fare all'inizio, ma si sa, per la presunzione tipica dell'informatico bisogna trovare la soluzione da soli. :-)

Nelle varie righe del log, ho trovato queste:

• [Source for Excel Connection Manager [18]] Error: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.  The AcquireConnection method call to the connection manager "Excel Connection Manager" failed with error code 0xC00F9304.  There may be error messages posted before this with more information on why the AcquireConnection method call failed.
• [SSIS.Pipeline] Error: component "Source for Excel Connection Manager" (18) failed validation and returned error code 0xC020801C.
• [Connection manager "Excel Connection Manager"] Error: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available.

Però c'era dopo. L'ultima riga da la spiegazione. La connessione ad Excel non è supportata negli Integration Services, in quanto non è disponibile alcun provider OLE DB a 64 bit. Come confermato anche dall'MSDN.

Ed in effetti questa era proprio la causa del problema. Io da un mesetto circa sono passato a lavorare su un portatile con Windows 7 a 64 bit. Per risolvere il problema al momento, sono passato sul vecchio portatile ed ho completato in 5 minuti la procedura.

Poi dopo sono andato ad investigare sul problema. Mi lascia un pochino perplesso che Microsoft non abbia ancora sviluppato un provider a 64 bit per i prodotti Office. In fondo tutti i nuovi computer iniziano ad avere Windows 7 a 64 bit per sfruttare completamente i 4 giga di RAM che sono ormai alla base del mercato di ogni PC. Non supportare completamente uno dei propri cavalli di battaglia, Office, potrebbe essere un problema. Comunque non sono io a fare le strategie di marketing di Microsoft. Sicuramente come utente esperto, la cosa mi lascia un po' di disappunto.

In effetti questo è la causa di un altro problema che ci ha fatto perdere alcune ore nello sviluppo di una applicazione WPF, ma di questo ne parlerò in futuro.

Dato che non tutti hanno un sistema a 32 bit configurato da usare in caso di problemi (io non avevo dismesso il vecchio computer per problemi come questo), sono andato a cercare come risolvere la questione dai 64 bit.

Su Visual Studio, dal quale creiamo i pacchetti SSIS, occorre andare sulle proprietà del progetto, poi su Debugging ed infine mettere a falso Run64BitRuntime.

Visual Studio debug a 32 bit - clicca per ingrandire.

Mentre se eseguiamo il pacchetto SSIS dall'SQL Server Agent come job pianificato, allora dobbiamo andare nelle proprietà dello step dal quale eseguiamo il pacchetto e specificare l'esecuzione a 32 bit.

SQL Server Agent esecuzione a 32 bit - clicca per ingrandire

In conclusione posso dire, che almeno dal mio punto di vista, il passaggio ad un sistema a 64 bit per un uso professionale del computer è un passaggio obbligato per poter sfruttare RAM superiori ai 3 giga, ed avere computer più reattivi e produttivi. Qua e là ci sta qualche intoppo, però nulla che non si possa aggirare in qualche modo. Anche se la cosa è un po' fastidiosa.