This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it possible to deploy SSIS 2012 package on SQL Server 2008
currently I have Visual Studio 2010 and SQL Server 2012 on my pc. Now I want to create a SSIS package, which should run on a SQL Server 2008.
If I create it normally, I just get the following error, if I try to load it on the server:
The package failed to load due to error 0xc0010014 "[...]" This occurs
when CPackage::LoadFromXML fails.
If I try to open it with BIS 2008, then I get a similar error.
Is there any way to change my dtsx so that it will work on a SQL Server 2008?
You can't. Packages have changed since 2008 : the XML structure is not the same. Packages created for SQL Server 2012 will only run for that technology. To have a 2008 package, create it using BIDS 2008.
Related
Will SSIS package developed in Visual Studio 2010 run on SQL Server 2012 environment? I'm trying to create a new package in VS 2010 but the server runs SQL Server 2012 will it work ?
I'm fairly sure yes it will as 2012 is backwards compatible. But #christiandev is correct, try a small/simple package and try it.
First, I'm loving the very clearly delineated versioning of the SSIS tools. >:(
I installed SSDT BI for Visual Studio 2013 and built a nice little project in it to generate test data. Within VS 2013, I ran this thing hundreds of times. I can deploy it from within the IDE (right click on project...deploy). However I can't deploy it using the .ispac file.
After much searching, I figured out that VS 2013 is building SSIS 2014 .ispac files (PackageFormat=8) and these won't deploy to a SSIS 2012 server (PackageFormat=6).
My question is, if VS can deploy the package built in VS 2013 to SSIS 2012, is there a way to get this to happen via the .ispac file? I can't deploy to any of my servers (only locally), because I'm not in the same domain (actually, I'm working locally, outside of a domain).
Yeah - the 'versioning' is awesome! NOT.. The simple answer to this is NO, you cannot use a SSIS package built in VS 2013 on Sql Server 2012 - you can deploy is and set it up, etc - but you will get that version 8 to version 6 nonsense..
This link sql-server-data-tools-business-intelligence-for-visual-studio-2013-ssdt-bi gives you a pretty picture that basically states with VS 2013 you can do SSRS and SSAS on Sql Server 2008, 2012, and 2014 but SSIS only on 2014..
To deploy SSIS packages to SQL Server 2012 you need to build and deploy from VS 2010 or 2012...
Here is the page that explains all the versions - Interoperability and Coexistence (Integration Services) I tried to post the individual links - but I'm new and not allowed...
Hope this helps - this was driving me crazy...
To answer your question directly, no, there is no way to fix the issue in the .ispac file. The dtsx files are different in a couple of ways in SQL Server 2012 and 2014. The only solution I found is to downgrade my packages from VS 2013 to VS 2012.
In case you've already developed significant work in Visual Studio 2013 only to realize that you can't deploy it on SQL Server 2012, I found a workaround how you can "downgrade" your SSIS 2014 packages to SSIS 2012. I wrote it on my blog here:
http://vaniecastro.com/2015/02/26/how-to-downgrade-sql-server-integration-services-2014-packages-to-2012/
The idea is that you need to manually modify the XML file, change the PackageFormatVersion and replace ExecutableType property and componentClassID attribute values to use the DTSX2 Version 2012/01 values instead of the DTSX2 Version 2014/01 ones.
Ive been working on some stuff with Visual Studio 2008, and SQL 2008 aswell..
Then i opened the project on another computer with 2012 version.
And now when im trying to work with the files in 2008 again, i cant open my database.mdf, becouse the 2012 sql has upgraded my database file...
Anything i can do to save it?
(Btw. the data aint that important, but more the whole table setup and relations)
Install 2012 SQL Server Express with Management tools, attach the MDF and extract the schema by generating "create" scripts for the objects you want using the wizard, then re-run the scripts on the new 2008 DB, don't think there's a way to downgrade. See here.
Or you can just keep developing on top of SQL2012, shouldn't be a problem even if you use visual studio 2008.
The problem I have is that I'm unable to open my mdf file in Visual Studio 2010. I installed VS2010 along time ago, but just installed SQL server 2008 R2 few days ago.
I made the file in VS2010 and then attach it to SQL server in Management Studio to run a script I have to create all tables and such.
I then detach it in Management Studio and try to view it in VS2010 and get an error telling me that I cannot open database version 661. I can only go as high as 655.
I know this is because VS2010 is using SQL server 2008, but Management Studio is SQL Server 2008 R2.
How can I make VS2010 compatible with SQL Server 2008 R2?
You simply need to upgrade the local version 2008 Express to R2. You'd be able to open your file after that.
I had this problem too, but my problem was solved when I did this:
When you are opening SQL Server Managemnt Studio, in the connect to server window, type "\SQLEXPRESS" after the server name (your server name\SQLEXPRESS), then attach your database. When you detach it, it is compatible with VS2010. I hope this helps you.
When I try to build a project in Visual Studio 2005 that has a .dtproj file, I get the error message:
Make sure the application for the project type (.dtproj) is installed.
This project was build on another system, but even after installing SQL Server 2005 & and SQL SP3, it still does not build.
You need to install the Business Intelligence Studio that is a part of the SQL Server Installation.
You may be missing development tools from your installation of SQL Server.
On my workstation at work I have VS.NET 2005, 2008 and 2010 loaded and needed to modify a package created in a 2005 environment. I only had SQL Server 2008 installed and therefore the BIDS environment for 2008 SSIS development. I had to go back and get the install for SQL Server 2005 and installed only the Integration Services component (instead of the entire SQL Server 2005 setup) and it resolved the issue mentioned above.