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
Related
I have a working SSIS project locally done by me with SQL Server Data Tools. I found out that the easiest way to have the project deployed in SQL Server is using the option "deploy", available on that IDE. I have done it successfully locally.
My problem is that I am not able to deploy the project directly to the client Server beacuse I have been ordered to give him no more than files, scripts , etc. in order to get the project deployed only by him. He cannot instal SQL Server Data Tools and deploy. I wonder if I can export my already deployed project in my local SQL Server instance and make him to import it?
You can give him the .ispac file from your SSDT project's /bin folder, and he will be able to import it to the SQL Server using SSMS.
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.
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity
I have a visual studio solution with an ASP.NET 3.5 web application (WCF host) and a test project. I wanted to use the Oracle Instant Client (v11, via NHibernate) to create Oracle connections without having the Oracle client tools installed on every "involved" machine (dev, CI server, test server, production server).
The weird thing is that on my development machine (x86) my tests run without problem, while my web application still gives me the following error message: System.Data.OracleClient requires Oracle client software version 8.1.7 or greater
Things I ruled out already:
The bin folder has read & execute permissions for everyone
The DLL's are unblocked (windows 7)
Problem occurs with both Visual Studio Development Server and IIS 7
I've also tested this on a machine with Oracle client tools installed and that works
I even managed to get the tests running on our x64 CI server (more info).
Anyone has a clue on what I am missing?
I see this error almost every time I set up Oracle on a new machine.
Check that the oracle bin folder is in your path
Give read and execute permission to everyone on the client folder (on my machine C:\oracle\product\10.2.0\client_1)
Changing permissions may not take effect until you reboot your machine.
EDIT:
From your comment, steps 2 and 3 are irrelevant for Oracle Instant Client. Hoverer, I would guess that the problem is still that the system cannot find the Oracle Instant Client DLLs. It would be worth putting the location of these DLLs into your path and seeing if this resolves it.
From http://www.oracle.com/technetwork/database/features/instant-client/index-100365.html
Installation Instructions
Installation Steps:
Download the appropriate Instant Client packages for your platform. All installations REQUIRE the Basic or Basic Lite package.
Unzip the packages into a single directory such as "instantclient".
Set the library loading path in your environment to the directory in Step 2 ("instantclient"). On many UNIX platforms, LD_LIBRARY_PATH is the appropriate environment variable. On Windows, PATH should be used.
Start your application and enjoy.
Best practices or tools for installing a SQL Server database
I have a SQL Server database designed with the SQL Server GUI database editor/Visual Studio.
What is the best way to "install" that database on other systems. Said another way how should I ship this thing?
I know I can save the scripts and set the primary/foreign keys with T-SQL but I suspect their is something better. I guess you could have people restore from backup but that does not seem very professional.
What other choices are there and what are the pluses and minuses?
For it to look professional make a small setup program.
You currently have sql scripts that you use to create your db.
Make yourself a small xml file that contains the path to your scripts.
Create a small c# library that will connect to the db server, and run those scripts.
You can test this outside of the setup, in visual studio, then add it to the setup like this.
To do this from your setup all you have to do is put the xml file in a component so it is deployed,
And create a custom action in your setup, that will call your C# lib, read the xml and run the scripts on the sql server to create your db.
Also, from a setup program it's easy to set a registry key to identify the version of the your db that you just installed.
The minuses and pluses: It's a bit of work to start with, but with this you'll have all the ground work done to handle upgrades automatically later on, to do so, just add an upgradeScript section to your xml, an attribute called version for each upgrade script, and simply compare it against the version of the db you have save in the registry. The advantage is this way it can easily scale with your project.
My previous answer is mostly to keep full control on the deployment and upgrades.
I have searched for more built-in and streamlined solution that goes along with the DB designer mode you have used.
I found that in the version Studio 2005 Team Edition for Database Professionals of visual studio there might be deployment features.
Build and Deployment
You've seen that you can generate a
T-SQL update script manually via the
Schema Comparison tool. However, as
part of the build process, DB Pro
edition can generate a complete script
for deploying your database project.
This deployment script can do either a
complete build or an incremental
update. The build process can even
consolidate all of your pre- and
post-deployment scripts into one
complete deployment script. You can
deploy the script via the Build |
Deploy Selection command right from
within Visual Studio 2005. Under
project properties, you will find a
number of options to control and
adjust the build process. The Build
tab contains the core settings, such
as Target connection, Target database
name, and Block incremental deployment
if data loss might occur. You'll note
there is also a Build Events tab that
you can use to type pre- or post-build
event commands. DB Pro edition uses
MSBuild for its build process and
supports integration with Team Build
if you're using Team Foundation
Server.