My machine has the current (March 2014) version of SSDT, Visual Studio 2012 Professional, and SQL Server 2014 Developer. I have a SQL Server project (let's call it MyProject.sqlproj) that targets SQL Server 2014. I attempted the following:
MsBuild.exe MyProject.sqlproj
/t:SqlPublish /p:SqlPublishProfilePath=Somewhere.publish.xml
This fails with the following error:
Deploy error Deploy 72002: Internal Error.
The database platform service with type
Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider is not
valid. You must make sure the service is loaded, or you must provide
the full type name of a valid database platform service.
If I switch this project to target 2012 (and point to a 2012 instance), this same command runs successfully. I had previously asked a potentially related question, and the answer there resolved my problem then, but that's not the issue here -- I'm able to publish this 2014 DACPAC successfully if I use SqlPackage.exe directly.
What's happening, and how can I fix it?
The issue here is that the VisualStudioVersion environment variable isn't set, in which case the .sqlproj file currently defaults to targeting the VS2010 version (which does not support SQL Server 2014). Calling "set VisualStudioVersion=11.0" before running MSBuild will fix the issue.
Related
Hello we have some SSIS packages with XML file configurations. Basically we configure the database connection, password, etc. to run the packages in different environment (Production vs. Testing). We use a 3rd party software to run our SSIS packages on target SQL servers. The packages run fine on our Testing environment, however fail miserably on Production server. The difference is SQL server on testing is vs. 2016, while on Production only 2012.
There are various error messages on why they fail on production, some of them about "Failed to load at least one of the configuration entries for the package..". And then there are some that cannot login to the database connection provided in the XML files, even though the info is 100% correct.
Does anyone know if XML config file is not supported in SQL 2012?
You really shouldn't be going from a test environment that's a different version than your production environment, it will only lead to more headache in the future.
If you can't upgrade production then I'd suggest getting another test system on the same version as production.
That being said...
The functionality is there in 2012, but the format probably isn't the same.
You need to set the TargetServerVersion to SQL Server 2012 in Visual Studio under Project > Properties and build the project again.
Project Properties
I have seen other posts about this topic where some of the suggestions lead people to check the ProtectionLevel to DontSaveSensitive. I have made sure that is set to DontSaveSenistive, as well as I have checked permissions and made sure where the files/dtsx files are getting called from have ample permissions set for the service account which owns the SQL Agent.
The odd thing is this process was working fine until i went into one of the previous dtsx files and had to update a datatype precision to go from a limit of 1 character to 30 characters. That was literally the only change made to the process, but now I am getting this error. I have gotten this error before, which is when I was set on the path to checking protection level and permissions/ownership. For some reason it went away and began working when i made those changes. None of that stuff (permissions/ownership) is incorrect this time around yet I am getting that same error.
Another weird thing about the process is that it is only the last step which is failing (the FTP step.) When I try to go in and execute the psftp.exe and put in the command which is being passed normally through SSIS execute process task step, the psftp.exe is telling me that the port number is incorrect..yet when I test connection on the connection manager inside VS with the exact same port, it says connection successful.
This error is vague and confusing!
I would love some guidance on some more things to try.
thank you !
SSIS tooling and version
SQL Server 2008 and 2008 R2 can only be edited using Visual Studio 2008 which has the Business Intelligence Design Studio templates installed. Those can only be acquired by having the physical SQL Server iso handy. Developer edition will work, but you need some form of licensed media to get BIDS working.
Visual Studio 2013 is going to attempt to upgrade 2008/R2 to the internals for a SQL Server 2012 installation. There is no going backwards/downgrading once this is done.
Any tooling (dtexec, dtutil, etc) you use must be from the same version otherwise, the first thing the binaries do is update the package to match that version. For execution (dtexec), each time you run a package, there is a delay as the original is upgraded in memory to match and then execution begins (assuming all goes well). It sounds like it's not based on
The package failed to load due to error 0xC0010014...
For deployment (dtutil), you only pay the price of upgrading once and then it's upgraded forever. Which probably isn't what you wanted. Be aware that tools like Visual Studio and SSMS "know" which version of tooling they are associated with so deploying from SSMS 2016 can result in the binaries for SQL Server 2016 SSIS upgrading your 2008 package to 2016 format and then attempting to deploy the now upgraded bits to your 2008 box. It's all very frustrating and not intuitive.
From your comment "In the 2008 version, the play button is greyed out..." That indicates you have opened a File in Visual Studio that is an SSIS package. Visual Studio will open it and paint all the icons on there but it can't actually run a package unless you have an Integration Services project open (and have the BI templates installed).
Assuming you have source control, you can rollback the change that broke everything and try to edit the package properly.
Execute process task
You have an Execute Process Task that is invoking psftp.exe and it's generating a 1 versus a 0. Is that bad? Based on previous workings with SFTP clients, they're rather picky so running it as me on production would fail since I didn't have whatever bits associated to my domain account but the service account had all the right things in their profile and it would run just fine - same machine, same package, just different user.
I am using SQL Server Data Tools 2012 version and Project Deployment Model.
I am getting below error while changing Protection level stage of the Deployment on Client's Testing Environment.
The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information can be stored.". This occurs when CPackage::LoadFromXML fails.
I have created Project parameters to provide Sharepoint Site Connection String and SQL Server Database Connection String.
( Overview of the SSIS Package : Extracting data from SharePointLists and then importing in SQL Tables.)
When I searched for this error, found many ways to set the package configurations for Package Deployment Model.
What is that thing which I am missing here in the configuration of Package, so that it is not able to encrypt decrypt the mentioned UserID and Password details ?
I have gone through many forums to get clear idea on this, but could not find any solution yet.
Is it something to do with the Integration Services Version and Deployment Utility version same on the Client environment as well ? Where exactly I should check the installed versions of them ?
The ProtectionLevel is set to : DontSaveSensitive
Please help.
Thank you,
Mittal.
The prob for me was the version of sql targeting. The sql target was 2016 while i was trying to deploy to sql server 2012. so just changed the targeting from VS project properties and it worked.
I faced this issue where i was getting 'changing protection level failure. Earlier I got package version issue when I run the package from catalog. Thats because i used latest sql server data tools in my development environment and version in dev environment was 8 but in server it requires 6. But even after deploying from server with sql 2012 version, the problem persists. Later I changed the target versions in the project properties as suggested by patricgh and it worked fine.
My case is slightly different but, in the similar lines.
Local SQL server version: SQL Server 2016
Server SQL server version: SQL Server 2012
If I open the ISPAC file on my local, the package gets converted to Version 8. But on the server, its version 6. So, if you try to deploy the version 8 package on SQL server 2012, you will get the following error.
Deployment failed on Changing Protection Level stage with XML Error
To resolve this, Open the ISPAC file on the server and build it. Then deploy the package on the server. It should get deployed successfully. Hope this helps.
Continuous Build Database Project fails when building on TFS server. We have Visual Studio 2013 Shell (Integrated) installed. There does not appear to be a way to install SQL Server Data Tools 2013 thru' Tools > Extensions and Updates... menu.
The redacted error is below...
C:\TFSBuild\XXX\XXX\Database_CI\Sources\Database\XXX\XXX.sqlproj (126): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Has anyone experienced this? Is there a solution or work-around? Is SSDT available for VS 2013 Shell for SQL Server 2014?
I have recently installed the Visual Studio Shell (Isolated) and (Integrated) on our build server and it does not include the SQL Server tooling components. I found out that SQL Server tooling is built in to the following versions of Visual Studio (see here):
Express for Web,
Express for Windows Desktop,
Professional,
Premium, and
Ultimate
I would recommend installing at least the Professional version and then you should get the SQL Server Data Tools components that are required for building.
SQL Server Tooling is now built into the above listed versions of Visual Studio 2013 (SSDT and Visual Studio versions) and the latest March update of Visual Studio 2013 now includes SQL Server 2014 support (SQL Server Data Tools for SQL Server 2014 is available.)
To force your build to use the correct version of MSBuild set the Process - Advanced - MSBuild arguments = "/p:VisualStudioVersion=12.0" (without the quotes) as shown.
You can download SSDT for VS2012 here and that should get the database pre-reqs on your build server.
I do see mention of "Sql Server Tooling in Visual Studio 2013" on this landing page, and I think it implies these tools should be available with the shell, so if you could, check to see if you have that targets file somewhere on your build server.
Go into C:\Program Files(x86)\ and do a "dir Microsoft.Data.Tools.Schema.SqlTasks.targets /s /b" and see if something comes up.
Right now it's hard-coded to this location:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
You might want to see if the file already exists, but in another location, like in an "v12.0" folder instead of the "v11.0" subfolder.
EDIT
Actually, what's the value on line 126 of your .sqlproj?
If it says this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Change it to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Then have everyone test it using diagnostic logging, then gather the logs and compare them to make sure that version is consistent so you can start phasing out the legacy bits.
I had the same issue and fixed it by downloading and installing the following
dacframework.msi
SQLDOM.MSI
SQLLS.MSI
SQLSysClrTypes.msi
from here:
https://www.microsoft.com/en-au/download/details.aspx?id=42295
I have created an application in Visual Studio that uses a .mdf database and executes SQL scripts on it. The program imports and exports reports to and from Excel. I want to be able to give this program to team members, but they get an error "error: 52 - Unable to locate a local database runtime installation. verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled."
I assume they get this error because they do not have SQL Server installed. Is there anyway I can include the minimum SQL Server components needed within my deployment? What is the minimum requirement? Thank you!