SQLBlog Nederland Business Intelligence & Datawarehousing
De SSIS Excel-connector is een speciale connector welke niet veel configuratiemogelijkheden heeft maar precies doet wat hij zou moeten doen: data vanuit een Excel-tabblad lezen en het erin terugschrijven. Behalve als je op een 64-bits omgeving werkt.
Nu heeft mijn huidige klant een hele mooie SQL-server omgeving staan op een dikke 64-bits server met 4 processoren en een paar GB geheugen. Dit werkt allemaal extreem goed en snel en is iets wat ik iedereen zou toewensen als werkomgeving. Het probleem is echter dat er binnen het bedrijf ook een hoop mensen zijn die graag met Excel werken en dat de informatie uit deze excel-sheets richting mijn Datawarehouse moet gaan.
Mijn eerste ingeving was om een SSIS-package te maken met een mooie Excel-connecter erin om zo de sheets uit te lezen en te verwerken. Lokaal op mijn 32-bits WindowsXP ging dit perfect, echter remote op de 64-bits Windows2003 wilde het pakket onder geen enkel beding werken.
Het probleem met een 64-bits omgeving is namelijk dat er blijkbaar geen 64-bits drivers bestaan voor connecties naar een JetDB-database, het formaat waarin Microsoft zijn Excel en Access oplossingen in aan wil spreken. Zonder deze driver is het dus niet mogelijk om verbinding te maken met een excel-sheet of een access-database.
Dit leidt ertoe dat het gebruik van een Excel-connector dus niet gaat werken zodra je het betreffende package naar een 64-bits omgeving deployed.
Microsoft heeft ook aangegeven niet van plan te zijn een 64-bits driver hiervoor uit te brengen waardoor we dus een probleem hebben.
Nu heb ik na wat zoekwerk en puzzelen 2 oplossingen gevonden:
Draai je SSIS-package met Excel-connectoren onder 32-bits executables
Een SQL-server 64-bits installatie installeert ook de 32-bits executables mee van onder andere de DTExec (de executable welke de packages onder water aanroept).
Een oplossing voor mijn probleem zou zijn om mijn pakketje uit te voeren met behulp van deze executable.
Nu voer ik doorgaans mijn pakketten uit met behulp van een SQL-job waar de betreffende Jobstep er als volgt uitziet:
Je ziet hier in het Command Line tabje precies wat de Jobstep onder water gebruikt om mijn pakket uit te voeren. Dit zijn namelijk de parameters welke meegegeven worden aan DTExec zodat hij weet welke pakket hoe uitgevoerd moet worden.
Deze informatie kunnen we gebruiken door in plaats van mijn pakket als een “SQL Server Integration Services Package” aan te roepen te kiezen voor een anders step-type waarin we deze parameters kunnen gaan meegeven aan de goede (32-bits) DTExec.
Kies hiervoor dus het goede jobstep type “Operating System (CmdExec)” en geven als “Command:” het volgende commando mee:
{geshi xml:lang=”d” lines=”false”}
C:Program Files (x86)Microsoft SQL Server90DTSBinnDTExec.exe
/SQL “TESTTest” /SERVER “sql” /MAXCONCURRENT ” -1 ” /CHECKPOINTING OFF /REPORTING E{/geshi}
Op deze manier wordt het pakket uitgevoerd door de 32-bits DTExec welke wel gebruik kan maken van de 32-bits JetDB driver waardoor je geen problemen meer hebt met je excel-connector.
Excel? Flatfile!
Een andere oplossing is misschien wel sneller maar vaak ook iets wat vaak niet kan. Pak de excel-sheet en converteer hem naar een CSV zodat we een flat-file connector kunnen gebruiken. Dit is echter alleen mogelijk als je toegang hebt tot de excel-sheet en je gebruikers om kunnen gaan met CSV.
