De: Koen Verbeeck | Actualizat: 2018-07-31 | Comentarii (13) | Related: Mai multe > Dezvoltarea serviciilor de integrare

Problemă

SQL Server Data Tools (SSDT) este mediul de dezvoltare pentru crearea și întreținerea pachetelor și proiectelor Integration Services (SSIS). Din punct de vedere istoric, nu exista compatibilitate retroactivă, ceea ce înseamnă că, cu o versiune mai nouă de SSDT, nu se puteau crea pachete SSIS pentru o versiune mai veche de SSDT. Începând cu versiunea SQL Server 2016,SQL Server Data Tools suportă compatibilitatea retroactivă până la SQL Server 2012. Acest sfat explică noua caracteristică.

Soluție

Introducere

În mod istoric, fiecare versiune a SQL Server a fost însoțită de o versiune a unui mediu de dezvoltare a inteligenței afacerilor. Acesta a fost întotdeauna fie un set de șabloaneinstalate în Visual Studio, fie, dacă Visual Studio nu era deja prezent, un shellof de Visual Studio capabil doar să gestioneze proiecte BI. Cu acest instrument se puteau dezvolta proiecte Integration Services, Analysis Services și Reporting Services.Inițial, acest instrument a fost numit Business Intelligence Development Studio sau BIDS.În SQL Server 2012, a fost redenumit SQL Server Data Tools. Cu toate acestea, Microsofthadispunea și de un alt produs numit SQL Server Data Tools; cu acest instrument se puteau crea și gestiona proiecte de baze de date SQL Server. Instrumentul BI era disponibil pe suportul de instalare SQL Server, în timp ce instrumentul de baze de date era o descărcare separată (și gratuită). Deoarece acest lucru a provocat destul de multă confuzie, SSDT a fost redenumit în SQL ServerData Tools for Business Intelligence sau SSDT-BI. Începând cu SQL Server 2016, instrumentele BI sunt acum cuplate împreună cu instrumentul de baze de date, iar întregul set de instrumente se numește acumSQL Server Data Tools sau SSDT. O prezentare generală:

• SQL Server 2005 – Visual Studio 2005 (BIDS)
• SQL Server 2008 și 2008R2 – Visual Studio 2008 (BIDS)
• SQL Server 2012 – Visual Studio 2010 (SSDT, disponibil pe suportul de instalare SQL Server) sau Visual Studio 2012 (SSDT-BI, disponibil ca descărcare separată)
• SQL Server 2014 – Visual Studio 2013 (SSDT-BI, disponibil ca descărcare separată)
• SQL Server 2016 – Visual Studio 2015 (SSDT, disponibil ca descărcare separatăși încorporează, de asemenea, proiecte de baze de date)
• SQL Server 2017 – Visual Studio 2015 sau Visual Studio 2017 (SSDT)

Problema în acest caz a fost că SSIS nu avea niciun suport pentru compatibilitate retroactivă.De exemplu, dacă doreați să dezvoltați pachete pentru SQL Server 2008, aveați nevoie de VisualStudio 2008. Dacă voiai să dezvolți pentru SQL Server 2014, aveai nevoie de Visual Studio2013. Cu Visual Studio 2013, nu puteai dezvolta proiecte SSIS pentru SQL Server2008 sau orice altă versiune de SQL Server, cu excepția SQL Server 2014. Acest lucru însemna că, dacă ați lucrat cu mai multe versiuni de SSIS, ați ajuns să aveți o mulțime de versiuni diferite de Visual Studio pe mașina de dezvoltare.

Cele mai recente versiuni de SSDT (începând cu SQL Server 2016) rezolvă aceste probleme: prin introducerea compatibilității retroactive, puteți utiliza o singură versiune de SSDT pentru a dezvolta și întreține versiuni de proiecte SSIS de la 2012 până la 2017 și ulterior. Este important să rețineți că SSAS și SSRS suportă compatibilitatea retroactivă de ceva timp.

SSIS și compatibilitatea retroactivă

Cuvintele rămase din acest sfat au fost scrise folosind versiunea Visual Studio 2015 SSDT,împreună cu SQL Server 2016. Toate sfaturile oferite în acest sfat sunt valabile și pentru versiunile ulterioare.

În primul rând, trebuie să instalăm cea mai recentă versiune a versiunii de previzualizare Visual Studio 2015SSDT. Când deschideți suportul de instalare SQL Server 2016, puteți găsi un link către pagina de descărcare. Acesta conține, de asemenea, un link către pagina de descărcare a SQL Server Management Studio (SSMS), deoarece acesta este acum, de asemenea, o descărcare separată.

Crearea unui nou proiect

Când adăugați un nou proiect, puteți vedea că acum este posibil să creați proiecte de baze de date și proiecte BI, de asemenea, în SSDT.

În proprietățile proiectului, puteți seta versiunea SSIS țintă pe care SSDT o va utiliza pentru acest proiect.

Versiunea țintă implicită este SQL Server 2016 (în versiunile ulterioare ale SSIS aceasta va fi cea mai recentă versiune de SQL Server). SQL Server 2014 și SQL Server 2012sunt de asemenea acceptate, în timp ce versiunile mai vechi (2005 și 2008) nu sunt acceptate. Dacă aveți proiecte mai vechi decât SQL Server 2012, va trebui să le actualizați mai întâi înainte de a putea utiliza cea mai recentă versiune SSDT.

După ce este setată versiunea țintă, caseta de instrumente SSIS se va adapta în consecință. De exemplu, în SQL Server 2016 sunt disponibile noi sarcini Hadoop și puteți descărca sarcini Azure din pachetul de caracteristici Azure.

Când setați versiunea la SQL Server 2014, toate aceste sarcini noi vor dispărea din caseta de instrumente SSIS. Același lucru este valabil și pentru transformările fluxului de date introduseîn SQL Server 2016.

Când schimbați versiunea unui proiect, veți primi un avertisment că pachetele existente ar putea fi modificate:

Dacă folosiți totuși funcționalitatea SQL Server 2016, veți primi o eroare după ce ați setat versiunea țintă la o versiune anterioară la deschiderea pachetului:

Pachetul se va deschide în continuare, dar sarcinile, transformările sau managerii de conexiuni incriminate ar putea dispărea sau nu veți putea deschide un editor. Este posibilca trecerea înapoi la SQL Server 2016 să nu rezolve problema: obiectul ar putea fi în continuare stricat. În acest caz, nu există altă opțiune decât să eliminați obiectulși să-l adăugați din nou.

În momentul scrierii acestui articol, există câteva erori la comutarea între versiunile țintă. Puteți găsi o listă în postarea de pe blogul MSDNWhat’s New for SSIS 2016 RC0?”. Este posibil ca unele dintre acestea să fie deja rezolvateîn momentul în care citiți acest text.

Când aveți propriile componente personalizate în SSIS, trebuie să faceți câțiva pași suplimentari pentru a le face să funcționeze cu proprietatea versiune țintă. Joost vanRossum, MVP SQL Server, explică modul în care puteți face acest lucru în postarea sa de pe blogSwitching Target Server Versions for custom components.

Agregarea pachetelor existente în proiect

Când adăugați un pachet SSIS existent de la o versiune anterioară în proiect – de exemplu, un pachet SSIS 2012 într-un proiect 2016 – pachetul va fi actualizatpentru a se potrivi cu versiunea țintă.

Când versiunile se potrivesc, nu are loc nicio actualizare, bineînțeles, pachetul este adăugat direct la proiect. De asemenea, puteți adăuga pachete de la o versiune superioară la proiect,SSIS va încerca să le retrogradeze.

Testările arată însă că nu puteți avea întotdeauna încredere în acest mesaj. Chiar și cu un mesaj de succes, pachetul poate fi stricat dacă folosiți numai componente SQL Server 2016.

Deschiderea unui proiect existent

Când folosiți SSDT 2015 pentru a deschide un proiect creat cu o versiune anterioară de SSDT,asistentul de actualizare se va activa automat. Acest lucru înseamnă că toate pachetele sunt actualizate la SQL Server 2016.

Deși puteți în continuare să retrogradați proiectul la versiunea anterioară, trecerea prin procesul de actualizare este poate ceva ce nu doriți. Ca o alternativă,puteți edita fișierul de proiect și adăuga următoarea linie:

Aceasta va face ca SSDT 2015 să sară peste expertul de actualizare și să deschidă direct proiectulcu versiunea țintă corectă. Pentru SQL Server 2014, schimbați SQLServer2012în SQLServer2014, bineînțeles. Deși această soluție pare să funcționeze,editarea manuală a fișierului XML al proiectului nu este cu adevărat susținută. Sfatul meu este să creați un nou proiect gol, să setați versiunea țintă și apoi să începeți să adăugați pachete.

Părți de flux de control

Părțile de flux de control sunt introduse în sfatulSQL Server Integration Services 2016 Control Flow Templates Introduction (acestea au fost redenumite din șabloane în părți). În mod surprinzător, puteți lucra în continuare cu părțile fluxului de control dacă versiunea dvs. țintă nu este SQL Server2016. Acest lucru este posibil deoarece acestea sunt o caracteristică din timpul proiectării și nu influențează modul în care funcționează efectiv pachetele. În exemplul de aici am creat un proiect nou cuversiunea țintă setată la SQL Server 2014. Am creat o parte simplă de flux de controlși am adăugat-o la pachet.

Depanarea pachetului nu este o problemă.

Și puteți, de asemenea, să rulați pachetul în interiorul unui catalog SSIS SQL Server 2014:

Concluzie

Proprietatea Target Server Version introduce compatibilitate retroactivăpentru proiectul SSIS în SSDT 2015. Cu această nouă capacitate, o veche rană a SSIS a fost în cele din urmă rezolvată: puteți utiliza o singură versiune de Visual Studio pentru a vă gestiona proiectele SSISdiferite. Se recomandă să setați versiunea serverului la începutul proiectului și să nu o schimbați prea des, deoarece ar putea duce la probleme. vestea bună este că, cu SSDT 2015 și versiunile ulterioare, puteți utiliza, de asemenea, părți ale fluxului de control în proiectele dvs. mai vechi!

Pași următori

• Pentru mai multe informații despre diferitele versiuni ale SQL Server Data Tools:
  • TheSSDT Evolution
  • SQL 2014 CTP1, unde este BIDS-ul meu?
• Pentru mai multe informații despre piesele Control Flow, consultați sfatulSQL Server Integration Services 2016 Control Flow Templates Introduction.
• Pentru mai multe sfaturi despre SQL Server 2016, puteți utiliza această prezentare generală.

Ultima actualizare: 2018-07-31

Despre autor

Koen Verbeeck este un profesionist BI, specializat în stiva Microsoft BI, cu o dragoste deosebită pentru SSIS.
Vezi toate sfaturile mele

Resurse conexe

• Mai multe sfaturi de Business Intelligence…

.