Pierwszy błąd, który chciałbym rozwiązać, to „Menedżer połączeń programu Excel nie jest obsługiwany w 64-bitowej wersji SSIS, ponieważ żaden dostawca OLE DB nie jest dostępny”.
Gotowe sterowniki Excela istnieją tylko w 32-bitowej przestrzeni adresowej. BIDS/SSDT to aplikacja 32-bitowa, więc źródło i miejsca docelowe programu Excel działają bez zarzutu. Jednak, gdy uruchamiasz je z wiersza poleceń/agenta SQL, musisz jawnie użyć 32-bitowej wersji programu DTEXEC.
Krok 1 będzie polegał na upewnieniu się, że możesz uruchomić pakiet z wiersza poleceń na serwerze, na którym agent wykonuje jako Ty. Zakładając, że Twój SQL Server jest zainstalowany w zwykłej lokalizacji, prawdopodobnie masz do dyspozycji jeden z następujących plików DTEXEC.exe
C:\Program Files\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
c:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Będziesz chciał użyć wersji (x86). Przyszli czytelnicy, jeśli zdarzy ci się korzystać z 32 wersji systemu Windows (może Windows 2003), pierwsze 3 będą jedynymi dostępnymi opcjami. Jak wskazuje komunikat o błędzie Viveka, wykonuje on pakiet SSIS w trybie 64-bitowym.
dtexec zapewnia przełącznik wiersza poleceń /X86 aby umożliwić bezproblemowe korzystanie z tego samego pliku wykonywalnego dla operacji 32- i 64-bitowych. KŁAMSTWA! Dokumentacja mówi o tym, ale kto czyta dokumentację?
Ta opcja jest używana tylko przez agenta SQL Server. Ta opcja jest ignorowana, jeśli uruchomisz narzędzie dtexec w wierszu poleceń.
Musisz więc uruchomić swój pakiet, podając wyraźną ścieżkę
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe /file C:\folder\GICSReport.dtsx
W wynikach widzę komunikat „Nie udało się odszyfrować chronionego węzła XML”, a także stwierdzasz, że używasz plików konfiguracyjnych, więc najprawdopodobniej możesz zmienić swój PackageProtectionLevel z domyślnego EncryptSensitiveWithUserKey na DontSaveSensitive. Ta funkcja ma na celu zapobieganie przypadkowemu ujawnieniu poufnych danych (hasła), ale ponieważ masz już do czynienia z plikami konfiguracyjnymi, nie powinno to stanowić problemu. ... Właściwie może to być błąd jednego z innych poziomów ochrony pakietów teraz, kiedy o tym myślę.
W każdym razie spróbuj najpierw uruchomić 32-bitowy plik wykonywalny. Jeśli to nie zadziała, spróbuj zmienić poziom ochrony pakietu, jak wskazano. Jeśli którykolwiek z nich sprawi, że pakiet będzie działał zgodnie z oczekiwaniami, spróbuj uruchomić to samo polecenie z agenta SQL.
Jeśli to wszystko działa, zaznacz to jako odpowiedź. Jeśli nie, zaktualizuj zgłoszenie z bieżącym wygenerowanym błędem, a my poprosimy o więcej informacji.
