Jak zmienić wersję zadania skryptowego w SSIS?


10

Dodałem zadanie skryptowe do projektu SSIS w VS2015. Po wdrożeniu do SQL Server 2016 dostałem komunikat o błędzie, że version 15.0skrypt nie jest obsługiwany.

Gdzie to się dzieje version 15 come from? Czytając inne, podobne pytania na temat Przepełnienia stosu, widzę, że możesz ustawić docelową wersję projektu na SQL Server 2012 - co zrobiłem (docelowym celem wdrożenia jest SQL Server 2012).

Próbowałem także usunąć i ponownie utworzyć zadanie skryptu. I w informacjach o skrypcie mówi, że używa V10 z C #.

Jak mogę to rozwiązać?

Zadanie skryptu: Błąd: Wystąpił wyjątek podczas ładowania Zadania skryptu z pliku XML: System. Wyjątek: Zadanie skryptu „ST_a1ad9dc5972c42b68c12a13155f10b6d” ”używa skryptu w wersji 15.0, który nie jest obsługiwany w tej wersji usług integracji. Aby uruchomić pakiet, użyj Script Task, aby utworzyć nowy skrypt VSTA. W większości przypadków skrypty są konwertowane automatycznie w celu użycia obsługiwanej wersji po otwarciu pakietu SQL Server Integration Services w% SQL_PRODUCT_SHORT_NAME% Integration Services. w Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML (XmlElement elemProj, zdarzenia IDTSInfoEvents) ”

Otworzyłem również projekt w SSDT 2012 i przebudowałem pod inną nazwą. Ten sam błąd. Wygląda na to, że musi istnieć odniesienie, które nie zostało usunięte lub coś takiego.

Żadne z rozwiązań tego pytania ( /programming/34893267/ssis-script-task-vs15-not-work-when-deploy-on-sql-server-2014 ) nie działało.

Patrząc na XML w pakiecie, w którym znajduje się skrypt, mogę łatwo znaleźć to zadanie i nigdzie nie ma odniesienia do wersji 15.

=========== EDYCJA

Po skopiowaniu projektu na maszynę, na której znajduje się baza danych, otwarcie VS2015 i wdrożenie z tego miejsca pakiet jest wykonywany.

A potem, gdy wracam do mojej maszyny i tam buduję, nie robi tego.

Czy to błąd? Czy też robię coś głupiego, oczekując, że kompilacja wygeneruje taki sam kreator wdrażania, jak przy użyciu kreatora z VS ...

Mam SQL Server 2016 (13.0.4411.0), ssisdbma wersję schematu (13.0.1601.5).

Korzystam z pakietu usług integracji utworzonego w Visual Studio 2015. Ścieżka do komponentu skryptu: C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\VSTA14_IS_ST_CS_Template.vstaxNie pozwala mi na wykonanie pakietu za pośrednictwem katalogu usług integracji (z powodu komunikatu napotkanego przez Zacha). Wygląda jednak na to, że pozwoli mi to wykonać przez system plików (za pomocą agenta SQL). Nie wiem, czy to działa, zaktualizuje to po zakończeniu pakietu.


Zauważyłem to samo przy określaniu wersji pakietu. Zbudowałem projekt i skopiowałem kreatora, zapominając o zmianie docelowej wersji programu SQL Server. Wystąpił błąd, że wersja docelowa była zbyt wysoka. Kiedy przebudowałem z poprawioną wersją docelową, dostałem ten sam błąd, mimo że XML pokazał poprawioną wersję docelową
Zach Smith,

Odpowiedzi:


5

Wydaje mi się, że mam ten sam problem, a oto obejście mojego problemu.

Najpierw szczegóły:

  • Mam serwer SQL 2016 (13.0.4411.0)
  • SSISDB ma wersję schematu (13.0.1601.5)
  • Korzystam z pakietu usług integracyjnych utworzonego w Visual Studio
  • Składnik skryptu (który podaje, że jest to 2015 C #) ma ścieżkę: C: \ Program Files (x86) \ Microsoft SQL Server \ 130 \ DTS \ Binn \ VSTA14_IS_ST_CS_Template.vstax

Jeśli wdrożę do katalogu za pośrednictwem SSMS, nie pozwoli mi to wykonać pakietu za pośrednictwem katalogu usług integracji (z powodu komunikatu napotkanego przez Zacha - wersja 15.0 nie jest obsługiwana).

Obejście:

Jeśli wdrożę pakiet za pośrednictwem programu Visual Studio do „Katalogu usług integracji” w wymaganej instancji, ten komunikat zniknie i projekt zostanie pomyślnie uruchomiony. Nie jest to idealne, ponieważ powinniśmy być w stanie wdrożyć za pośrednictwem SSMS, ale oznaczało, że projekt może się rozwijać.


1
Chciałbym wiedzieć, dlaczego to obejście działa.
Zach Smith,

4

Mój DBA w końcu to dla mnie wymyślił i problem polegał na tym, że wdrażałem za pośrednictwem SSMS 2017, nie zdając sobie z tego sprawy. Komunikat o błędzie doprowadził mnie na manowce, ale twoje obejście pomogło mi znaleźć uzasadnienie niepowodzenia. Myślę, że możesz wypróbować SSMS 2016 i sprawdzić, czy to działa. Innym sposobem sugerowanym przez moją DBA jest użycie wiersza poleceń. Coś w tym stylu, z wyróżnieniem 130, ponieważ jest to wersja, której potrzebujesz na 2016 r .:

"C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\ISDeploymentWizard.exe" 
/Silent /ModelType:Project 
/SourcePath:"E:\ssis\Project Path\bin\Development\Project.ispac" 
/DestinationServer:"server01" 
/DestinationPath:"/SSISDB/Projects/Project"

Mam nadzieję, że to pomoże to wyjaśnić. Pracowałem nad tym przez długi, długi czas, zanim znalazłem twoje obejście, a następnie w końcu znalazłem to rozwiązanie. Więc dziękuję!


co rozumiesz przez „wdrażanie przez SSMS 2017, nie zdając sobie z tego sprawy”? Używam VS 2017 do wdrożenia .. i jest ustawienie, które pozwala zdefiniować wersję programu SQL Server, na który jesteś kierowany. Ale okazało się, że to nie zadziałało
Zach Smith,

To zadziałało dla mnie. Wdrażanie bezpośrednio z SSDT działało, ale nie mogliśmy tego zrobić zdalnie, wdrożenie za pośrednictwem SSMS 2017 nie działałoby, a następnie skorzystanie z opcji wiersza polecenia za pomocą ISDeploymentWizard.exe 2016 działało. Dzięki!
Clinemi

0

Podobnie do innych, pierwotnie wdrożyłem SQL2014 przy użyciu kreatora wdrażania SQL2017. To spowodowało błąd środowiska wykonawczego. Kiedy korzystałem z kreatora wdrażania SQL2014, wszystko działało dobrze.


-1

Myślałem, że dodam do tego, ponieważ otrzymywałem ten sam błąd. Korzystam z VS 2017 i wdrażam na SQL Server 2016. Przeczytałem sporo artykułów, a potem zdałem sobie sprawę, jak łatwo było mi to naprawić. VS 2017 ma doskonałą kompatybilność wsteczną.

Ten artykuł na temat zmiany wersji pakietu SSIS w celu dopasowania do wersji serwera docelowego pomógł mi rozwiązać błąd w moim przypadku.


Zauważ, że OP powiedział, że próbował zmienić serwer docelowy w swoim przypadku, ale to nie zadziałało. Oczywiście (jak zauważono w artykule), gdyby użył funkcji niedostępnej w wersji docelowej, rzeczy nie działałyby z tego powodu.
RDFozz

Tak - zmiana wersji docelowej nie działała. Jednak zmiana wersji docelowej, a następnie lokalne wdrożenie za pośrednictwem VS 2017 zadziałało - podejrzewam więc błąd w VS 2017 (przynajmniej kiedy zadałem pytanie) w odniesieniu do sposobu tworzenia kreatora wdrażania. (Zakładam, że ponieważ to podejście zadziałało, nie korzystałem z niekompatybilnych funkcji)
Zach Smith,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.