Gör några antaganden här, men jag kommer att anta att detta är ett 32 vs 64 bitars problem. För att verifiera, prova dessa två kommandon från en kommandotolk (Windows Key, R, cmd.exe eller Start, Run, cmd.exe)
"C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
Den första kör ditt paket i 32-bitarsläge medan den andra kör det i 64-bitarsläge. Detta kommer att spela någon roll eftersom dina drivrutiner och eventuella DSN:er du har skapat endast kommer att vara synliga i 32/64-bitarsvärlden.
Åtgärdar SSDT
När du har identifierat vilken du behöver, förmodligen 32-bitarsversionen, måste du se till att ditt projekt använder lämplig körtid. Högerklicka på ditt projekt och välj Egenskaper och navigera sedan till fliken Debugging under Konfigurationsegenskaper.
Efter att ha inverterat Run64BitRuntime-värdet antar jag att ditt paket kommer att fungera inifrån SSDT.
Åtgärda SQL Agent
Du måste redigera det befintliga SQL Agent-jobbet för att ändra jobbstegets bithet. Detta kommer att finnas under fliken Konfiguration och sedan under fliken Avancerat. Markera/avmarkera 32-bitars körtid.
Lögner och bedrägeri
Uppmärksamma människor kanske ser att dtexec erbjuder en /X86 alternativ. Tro inte det. Det enda sättet att få rätt bithet är att uttryckligen anropa rätt dtexec.exe. Dokumentationen säger till och med lika mycket men ingen läser dokumentationen.
Det här alternativet används endast av SQL Server Agent. Det här alternativet ignoreras om du kör verktyget dtexec vid kommandotolken.