I've been trying to test whether a project (DB, SSIS, SSAS) built on SQL Server 2014 will be compatible with SQL Server 2012. I've got a .dproj packed in dacpac format and when I try to run this from cmd:
sqlpackage.exe /Action:Script /SourceFile:"Project.dacpac" /TargetDatabaseName:DBName /TargetServerName:"DBName /p:BlockOnPossibleDataLoss=false /p:RegisterDataTierApplication=true /p:BlockWhenDriftDetected=false /OutputPath:Logs\Output.sql
I get a following error:
*** Could not deploy package. Internal Error. The database platform service with type Microsoft.Data.Tools.Sch
ema.Sql.Sql120DatabaseSchemaProvider is not valid. You must make sure
the servic e is loaded, or you must provide the full type name of a
valid database platform service.
I created a VM on Azure with SQL Server installed. Apart from that I installed Data Tools for VS 2012. I'm guessing that it might be compatibility problem, but maybe there's a workaround this without changing DT to a higher version? Any patch that could be applied?
You can install a more recent dacfx (sqlpackage) or you can copy the DAC folder from a more recent version to the deploy machine and use that instance of sqlpackage.exe to deploy.
You can also set the properties in the project itself to target SQL Server 2012 and it will validate that the T-SQL is correct for SQL Server 2012 and let you deploy to it.
There were lots of fixes between sqlpackage 2012 and 2014 so I would move them onto a newer version of sqlpackage even if you still target a SQL Server 2012 box.
This is only for dacpacs, not sure about the other projects.
Related
We recently updated our production SQL Server 2016 Enterprise instance from SP1 to SP2. We are currently on version 13.0.5026. Prior to the upgrade, a user with connect rights to SSISDB and proper rights on the Integration Services Catalog folder could deploy an ISPAC file successfully.
After the upgrade, the same users can still deploy to the SSISDB, but when you execute the .DTSX, the script task inside fails validation. If I deploy the exact same ISPAC as a sysadmin, there's no issue. The usual solution I've seen is to confirm that SSDT Configuration Properties are set to SQL Server 2016. We have verified this is set correctly prior to building the ISPAC.
I saw a similar issue when migrating from SQL Server 2014 to 2016 a couple years back, but the solution at that time was to give the Proxy account that runs the package modify rights to the C:\Windows\Temp folder so it can generate temp files. This new issue is hard to pin down, and I don't want to give out sysadmin just so others can do the simple deployment steps.
Any thoughts or suggestions are appreciated.
*******Update/edit************:
The server has a SQL Server 2016 deployment tool located under SQL Server/130/DTS/Binn - ISDeploymentWizard.exe. This deployment tool works. There is another identical wizard under the 140/DTS/Binn location, same name but 1 KB larger (assuming this is because SSMS is a separate install now, and I installed latest and greatest on server). This one fails deployment. I'm banging my head against the wall as to why one works but the other doesn't. Locally we all use SSMS 2017, and with that we get the 140/DTS/Binn ISDeployment file, not the 130 (since that's SQL Server 2016 and we're using SSMS 2017, which I thought was backwards compatible). Either way, this problem just started occurring and we've been on the same version of SSMS for a few months.
Image of the Execution information report from SSMS
Had resolved a similar issue with C# scripts recently. In short: don't use 140 version of ISDeploymentWizard.exe with MS SQL 2016. It apparently mangles something in C# code, or components' properties, and 2016 runtime stops recognising them.
In my case, a package with C# script source has started to throw the following error during the validation phase:
Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:
The version of C# source component name is not compatible with this
version of the DataFlow. [[The version or pipeline version or both for
the specified component is higher than the current version. This
package was probably created on a new version of DTS or the component
than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100
wrapper, Int32 lPipelineVersion)
The first comment here has helped me to ultimately identify the cause.
Hi I'm looking for some guidance.
I've developed an SSIS project with a couple of script tasks and script components using visual studio 2015 for targeted version 2016.
I have two environment server A and server B both have SSIS 2016 SP1 installed on it.
I have done a project deployed of the packages to Sever A and tested the packages everything executed perfectly.
However when I deployed the packages in SSIS_DB from Server A to Server B I get these errors in my execution report.
The component metadata for "script component, clsid { }" could not be upgraded to the newer version of the component. The PerformUpgrade method failed
2
There was an exception while loading Script Task from XML: System.Exception: The Script Task "" uses version 15.0 script that is not supported in this release of Integration Services. To run the package, use the Script Task to create a new VSTA script. In most cases, scripts are converted automatically to use a supported version, when you open a SQL Server Integration Services package in %SQL_PRODUCT_SHORT_NAME% Integration Services.
at Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask.LoadFromXML(XmlElement elemProj, IDTSInfoEvents events)
The interesting part is if I deploy my packages directly from visual studio to Server B the packages executes correctly with no issue.
So there seems to be inconsistencies between server A and Server B.
A small background to this is that when both servers were built Server A had Microsoft SQL Server 2016 (SP1-GDR) and Server Microsoft SQL Server 2016 (RTM)
but they both now have Microsoft SQL Server 2016 (SP1-GDR) after Server B was updated.
I'm not sure how the upgrade was done by my suspicion is that the SSIS on server are different but I can't seem to prove it.
when I check the version they both seem to return same or similar meta data
The right answer is here: https://andyleonard.blog/2017/09/ssis-version-15-0-script-error/
In my case the problem was the setting at the project level “TargetServerLevel” set to “SQL Server 2017”. The correct value must be “SQL Server 2016”. Once the value is changed and the project redeployed errors desappear.
I believe one of developers in my team used VS 2017 when added the project. All other tasks and components, excep script, were fine even with incorrect server version and the problem appeared only when I had to use script tasks and components.
To fix the problem open project parameters => Configuration Properties => TargetServerVersion
Select “SQL Server 2016”, then deploy to the server.
This was caused by SSMS. I don’t know what’s going on under the hood but During the deployment I was using SSMS 2017 which seems to be upgrading script components in my packages. I changed to use SSMS 2016 and this issue disappeared
Just summarizing some things because there are some reasons for facing this problem:
Your are deploying a package with Target Version Definition for another SQL Server
You are deploying a package which contains a script task with not same SSMS version as SQL Server Version
If your package doesn't contain a script task for example, then any version of SSMS can deploy the package to any version of SQL Server via SSISDB catalog. Not sure why is this happening. Seems that you can deploy and execute packages while making sure that the package target version is supported from SQL Version, but also if you have a ScriptTask inside you need to be super careful and make sure also that the integration services version of SSMS is the same with SQL Server version.
I will open a question to Microsoft just to be sure why the script task has this treatment. Maybe is because the script task is Framework dependent.
I have VS2015 Community and SQL Server 2016 Developer installed. Using the MSFT link, I've ensured to download the latest version of SSDT, which appears to install without error (though, Integration Services do not show in the SQL Configuration Manager). Using previously validated projects that creates and executes SSIS packages, I cannot get the same code to work with the current setup.
The error showing when I debug:
Component: SSIS.Pipeline
Error: To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition (64-bit) of Integration Services or higher.
I've uninstalled, reinstalled, repaired, modified, etc., but cannot get the package to build and execute. Has anyone seen similar issues with the setup mentioned?
As per my understanding
You need to install SQL Server and make sure to select Integration Services. Then run DTExec.exe from the new SQL server installation folder.
I have exactly the same issue. I ended up installing SQL Server 2017, SSMS 17.4 and VS 2017, SSDT for VS2017 and successfully run my packages FINALLY! It looks like SQL server and SSDT/VS version has to be "matched". Not sure if they have to be the same version though. But this is quite annoying.
So I am attempting to run SSIS packages that were developed with SQL2012, in VS13. Whenever I attempt to run the package it pops up saying that the package was upgraded. I have confirmed this upgrade by observing a change in the "PackageFormatVersion" in a text editor.
I have found this solution from microsoft: In the property pages for an Integration Services project, on the General tab of Configuration Properties, select the TargetServerVersion property and choose SQL Server 2016, SQL Server 2014, or SQL Server 2012.
However, when i click on my property pages I do not have a general tab (or any place that has an option to select which version of sql server i am using).
I have included an image of what my property pages look like. Also it is a dtproj file that I am using.
img
Only the Visual Studio 2015 editor allows you to specify whether your integration services project is built upon the SQL Server 2012, SQL Server 2014 or SQL Server 2016 technology.
Using any up version tooling results in the package being upgraded in place. So, what you are experiencing is normal.
If you have a full installation of SQL Server on your machine, you can run the packages from the commandline and while they will still upgrade to run, that upgrade will only be in memory and the original file on disk will remain at the earlier version.
On the SQL Server installation media, you need to specify that you want Integration Services Service installed. That is the only way to run SSIS packages outside of Visual Studio/SSDT.
I'm getting this error while importing bacpac file from windows azure
TITLE: Microsoft SQL Server Management Studio
------------------------------
Count not load schema model from package. (Microsoft.SqlServer.Dac)
------------------------------
ADDITIONAL INFORMATION:
Internal Error. The internal target platform type SqlAzureDatabaseSchemaProvider
does not support schema file version '2.5'.
Most of the help online suggests upgrading SSDT, but I have the latest version of SSDT for VS2012 already installed
Update - with a number of new features including Query Store, it's now best to use the SQL Server Management Studio Preview to import. In some cases this will be necessary given updated features in the bacpac file. You can install this from its download page. On that download page choose "Download SQL Server Management Studio Preview" to install.
Original Answer
The best solution is to install SQL Server Management Studio 2014 from the Express download page. On that download page choose "MgmtStudio 32BIT\SQLManagementStudio_x86_ENU.exe" installer when clicking the download link. SSMS 2014 contains a more recent DacFx version that supports version 2.5 and has full support for SQL Server 2005-2014 dbs, along with Azure DBs.
A few notes on DacFx / SqlPackage:
Installing the latest SSDT won't fix the issue since SSDT no longer installs Dac DLLs in a shared location. Instead it installs them under the Visual Studio install dir (C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120).
To update DacFx binaries used in SSMS to the latest version you must install the DacFramework.msi directly. You can download the latest version for 2014 here (this will update the location used by SSMS 2014), or if you have to use SSMS 2012 the last version compatible with that is found here.
SqlPackage.exe does support bacpacs. You need to use the Import/Export actionsfor bacpacs rather than the Extract/Publish actions used for dacpacs.
It will not directly restore. As you already install "SQL Server Data Tools", please check links.
http://social.technet.microsoft.com/Forums/en-US/66a4dfeb-c626-45eb-af3c-00e7e5996203/bacpac-file-import-from-windows-azure-fails?forum=ssdt
Azure SQL Database Bacpac Local Restore
http://social.msdn.microsoft.com/forums/windowsazure/en-us/36035d1e-fda8-4388-99c4-ba2ff7c5a5e1/new-sql-azure-bacpac-format-not-working-with-sql-2012
http://saransh77.wordpress.com/2013/05/02/part-1-how-to-manually-backup-azure-sql-database-and-import-in-on-premise-sql-server/
It looks to me that something has recently changed Azure side to break even using SQL Server 2014 Management Studio. I had to install the Cumulative Update 5 onto SQL Server 2014 Management Studio to get this working again. Looks like Cumulative Update 6 is out so you could also try that.
I've updated my SQL Server 2012 with SP2 and then I could actually Import BACPAC files from Azure. You can try that.
I understand that this has been there for a while but those who have still this problem, this happens because of having an older version of Microsoft® SQL Server® Data-Tier Application Framework.
Installing the latest version solved the problem.
At the time I am writing this is the latest and I was using an older which was incompatible with the bacpac file I was trying to import.
http://www.microsoft.com/en-us/download/details.aspx?id=46898