Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Изпълнение на SSIS пакет с помощта на dtexec

Първата грешка, която бих адресирал, е „Диспечерът на връзки на Excel не се поддържа в 64-битовата версия на SSIS, тъй като не е наличен доставчик на OLE DB.“

Готовите драйвери на Excel съществуват само в 32-битовото адресно пространство. BIDS/SSDT е 32-битово приложение, така че източникът и дестинациите на Excel работят добре. Въпреки това, когато ги стартирате от командния ред/SQL агента, тогава трябва изрично да използвате 32-битовата версия на програмата DTEXEC.

Стъпка 1 ще бъде да гарантирате, че можете да стартирате пакета от командния ред на сървъра, на който агентът изпълнява като себе си. Ако приемем, че вашият SQL Server е инсталиран на обичайното място, вероятно имате един от следните 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

Ще искате да използвате версията (x86). Бъдещи читатели, ако случайно сте с 32 версия на Windows (Windows 2003, може би), първите 3 ще бъдат единствените налични за вас опции. Както показва съобщението за грешка на Вивек, той изпълнява SSIS пакет в 64-битов режим.

dtexec предоставя превключвател на командния ред /X86 за да ви позволи безпроблемно да използвате един и същ изпълним файл както за 32, така и за 64 битови операции. ЛЪЖИ! Документацията го извиква, но кой чете документацията?

Тази опция се използва само от SQL Server Agent. Тази опция се игнорира, ако стартирате помощната програма dtexec в командния ред.

Така че ще трябва да стартирате пакета си, като предоставите изричния път

C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe /file C:\folder\GICSReport.dtsx

Виждам „Неуспешно декриптиране на защитен XML възел“ във вашия изход и също така заявявате, че използвате конфигурационни файлове, така че най-вероятно можете да промените своя PackageProtectionLevel от EncryptSensitiveWithUserKey по подразбиране на DontSaveSensitive. Тази функция съществува, за да предотврати случайно излагане на чувствителни данни (пароли), но тъй като вече се справяте с това с конфигурационни файлове, това не би трябвало да е проблем. ... Това всъщност може да е грешка от някое от другите нива на защита на пакета сега, когато се замисля.

Във всеки случай опитайте първо да стартирате от 32-битовия изпълним файл. Ако това не работи, опитайте да промените нивото на защита на пакета, както е посочено. Ако някое от тях накара пакета да се изпълнява според очакванията, опитайте да изпълните същата команда от SQL агента.

Ако всичко работи, маркирайте това като отговор. Ако не, моля, актуализирайте билета с текущата генерирана грешка и ще поискаме повече информация.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да проверите дали съществува съхранена процедура, преди да я създадете

  2. Анализирайте името на файла и пътя от пълния път

  3. Как да направите изтриване на преминаваща заявка в SQL Server

  4. Външният ключ създава ли автоматично индекс?

  5. Какво е STATISTICS IO в SQL Server?