Hi
I am trying to build an SSIS package to import text files to SQL data tables and then move the text files to a 'processed' file.
I can get the package to run successfully on my workstation in Visual Studio 2005 (although I got 'access denied' on the 'move' operation but I will worry about that later).
However, when I deploy to the SQL server, and execute the package on the server, I get DTS_E_PRODUCTLEVELTOLOW error on the import to SQL stage. I have checked the SSIS service is running on the server which it is.
The data upload is very simple - just the first column from the text file plus the file name in two columns, so none of the 'smart' stuff that might not be installed.
Can anyone help?
Thanks!
http://msdn.microsoft.com/en-us/library/aa337371.aspx
says
Possible Causes
This message might appear because of one of the following problems:
You have installed BI Development Studio but you have not installed Integration Services. Running packages outside Business Intelligence Development Studio requires the installation of Integration Services.
Your package may be attempting to use advanced components for Analysis Services, data mining, or text mining that are available only in SQL Server Enterprise.
In the unlikely case you are using SQL Server 2005 without any service packs, there was a problem with running the Import-/Export Data Wizard. This problem was solved beginning with SP1.
A great collection of tips are in this blog post:
http://blogs.msdn.com/b/michen/archive/2006/11/11/ssis-product-level-is-insufficient.aspx
Update:
To find out, what SQL Server Version you are running, execute the following query on your server:
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
The second column of the result tells you the service pack level.
Related
I got VS 2017 15.8.1 version installed and a legacy SSIS package created and run in VS 2012 version 11.0.61219.00 Update 5. So basically two VS instances on one machine. I also installed SSDT 15.4.0 version for VS 2017. My app saves .csv file on the server, makes a call to SQL Server 2016 which invokes SSIS packages and passes the address of .csv file to it. SSIS processes the file and saves data to the database. All this is working correctly, however, instead of displaying the uploaded file on page as a link the UI throws the following error.
"Error: 2019-05-09 12:06:03.61, Code: 0xC000F427, Source:
SCR_Chk_UploadTypes, Description: To run a SSIS package outside of SQL
Server Data Tools you must install SCR_Chk_UploadTypes of Integration
Services or higher.,End Error,DTExec: The package execution returned
DTSER_FAILURE (1)."
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have some relation to SSDT and VS compatibility.
Thanks!
Any ideas what "SCR_Chk_UploadTypes" is? I'm guessing it might have
some relation to SSDT and VS compatibility.
I imagine that is either the name of a connection manager or a Data Source in the data flow(s). Can you post a screenshot?
With respect to the error itself, please note that Microsoft requires a package to target a specific version of SQL Server.
The package that runs in VS2012 can only target SQL Server 2012.
Starting with VS2015, Microsoft introduced the concept of Server targeting. By default, when creating a package in VS2017 the targeted SQL Server will be SQL Server 2017. Have you confirmed that the SQL Server version that the package is targeting is SQL Server 2016?
For more information on targeting
TLDR; I am attempting to connect to a host and hitting "To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher". Does SSIS need to be installed on all Hosts for my package to succeed? Secondary question: If so, why would a manual execution from my dev machine work while the deployed/dtexec versions fail?
Apologies if this is a basic question (I am still steeping myself in all things SSIS and trying to learn as quickly as possible). Thanks in advance for any assistance you can provide!
I have a package that runs fine on my development machine (via Visual Studio). However, when I deploy the package out I encounter errors when attempting to connect to a MySQL database on a secondary host machine on the network. Taking a step back, I decided to attempt a manual execution via DTEXEC on my dev machine to attempt troubleshooting...
When executing this package through DTEXEC however, I encounter an error stating:
"To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher"
Looking at the log, it looks like the package is able to connect to Host 1 successfully and do some data manipulation (one of the 3 hosts; I know Host 1 and Host 3 have SSIS installed). However, when it attempts connection to Host 2, it fails with the aforementioned error. For the longest time, I thought this was due to the MySQL database I am trying to connect to (using .net Provider\MySQL Data Provider) but given the error above, it is possibly pointing to something else...
After doing a bit of searching I have located the following articles which may be related:
https://dba.stackexchange.com/questions/49786/error-to-run-a-ssis-package-outside-of-sql-server-data-tools-you-must-install
Getting error running SSIS package on non-SSIS Server
I know SSIS isn't installed on Host 2. The package is being executed from Host 1 and this host does have SQL Server and SSIS installed. Host 3 additionally has SQL Server and SSIS installed and I am able to successfully operate/connect on this host as well. The only host presenting a problem is Host 2 which does not have SQL Server nor SSIS installed.
Do all hosts have to have SSIS installed for connections to be made? Additionally, if SSIS does need to installed on Host 2, why would my dev machine succeed while the dtexec/deployed versions fail?
Again, thank you for any assistance you can provide!
The answer to your first question is "Yes", and that fact is the answer to your secondary question.
In short, SSIS packages are NOT self-contained executable files. They are more like .ini files that the SSIS Service reads, interprets, and executes. If the SSIS Service is not running on a host computer, then that computer cannot do anything with an SSIS package (the .dtsx file).
Your dev machine succeeds because it has Visual Studio, or BIDS, which is a developer's version of the SSIS Service engine.
I am creating my first SSIS package using Business Intelligence in Visual Studio 2012. I am adding the contents of an Excel sheet to an local VS database. In the Destination Assistant I am asked Destination Type = SQL Server, New: Provider - I see no .NET Framework option. The result seems to be that I am then unable to select my server and therefore databases.
Am I just missing the point?
I would recommend that you investigate the destination server and verify that you have the providers installed on that system. Typically these are installed at the time that SQL server is installed, but is possible via custom installation to specify the providers that are installed. It may be necessary for you to install any providers needed. A second option would be to point to a database that you know that you can connect to, say a localhost sandbox or other tried database. That would help you to determine if it's server side or client installation issues.
I'm running into this issue basically:
Can I deploy & Use SSIS SQL server DTS DLL's onto a machine that does not have SQL server 2008 installed?
Since it's been answered I don't know if my request for further information will get any traction.
I'm running into the same problem I think. When I deploy locally on my dev box, my application calling SSIS works fine. When I deploy my application on Server A, and my SSIS package on Server B (my database server), I get the error mentioned in the post: " An Integration Services class cannot be found. Make sure that Integration Services is correctly installed on the computer that is running the application. Also, make sure that the 64-bit version of Integration Services is installed if you are running a 64-bit application".
If I understand things correctly I need to have an SSIS license on my application Server and my database server?
This doesn't seem to make sense. When you make a SQL call to SQL server, provided you have an enterprise license you only pay once. You don't have to pay for an extra license for your application server.
I just want to make sure I've got this clear before I go to the higher ups, and that my problem isn't stemming from something else. So to put it concisely: Do you need to have an SSIS license for both your app server and your SQL Server when calling an SSIS package remotely?
Just to clarify the 64 vs 32 bit thing: I've got 64 bit OS's running on my local machine, the app server and the database server - and all my VS projects are being built to use "Any CPU".
Sorry for the lengthy post, but I thought I should be thorough on this.
You will need to have SSIS licensed (SQL Server) on any machine that is using SSIS to execute packages.
On my development machine I have Visual Studio 2010 and SQL Server 2008 Express. On our production server we have SQL Server 2008 Standard. I am going to create a WCF service that will reside on the production SQL server that will fire my SSIS package when called.
Because I have SQL Express on my development machine, I do not have access to create SSIS packages from this machine at all. This is needed so I can write the WCF service in the first place.
So, I could simply download SQL Server 2008 Standard from our msdn subscription to my development machine, but for reasons I cannot get into, this is not immediately possible. It will be in the near future but not soon enough.
How can I get this done? Are there tools to download? Where? I have researched this at length but there appears to be 5 different ways that lead to no where.
Since you have a licensed Edition of SQL Server on your network you can install the full suite of tools on your development server or your own desktop if you wish. This will give you access to BIDS software that SliverNinja mentioned.
I would say since you are limited to what can be done you only option would be to deploy a simple/basic package to your production server. If your development server can communicate with that server, I would say create your WCF service on the development box and have it simply call the package on your production server. The package does not have to do anything fancy to simply verify that you can call it correctly. Just have the package import a simple file and output it to a different file; or just export some catalog data from a database.
I do not see, since you are limited by not being able to duplicate your production environment on your dev server, that this would be unreasonable to do in this situation. If it has to get done, it has to get done.
So you want to create a package without BIDS?
Feel free to create one using plain text, there you go :)
<DTS:Executable xmlns:DTS="www.microsoft.com/SqlServer/Dts" DTS:ExecutableType="MSDTS.Package.1">
<DTS:Property DTS:Name="PackageFormatVersion">2</DTS:Property>
<DTS:Property DTS:Name="CreationDate" DTS:DataType="7">5/18/2012 1:21:47 PM</DTS:Property>
<DTS:Property DTS:Name="ProtectionLevel">1</DTS:Property>
<DTS:Property DTS:Name="DisableEventHandlers">0</DTS:Property>
.....a lot more properties.....
</DTS:Executable>
I'm joking, of course. My points are:
dtsx packages are merely XML files created by BIDS
you can create your package anywere, if you cant use your local box,
use what you have, even if that means to use your server (if that's
your only option, do it)
you dont need BIDS or even the SSIS service to run pacakges. DTEXEC,
DTEXECUI and SQl Server Agent are capable of running packages by
themselves (unless the packages are deployed to the package store)
I am not aware of any tool that builds packages other than BIDS. It
wouldn't make much sense, is like asking if there is a tool where you
can build C# application other than visual studio
You need BIDS (Business Intelligence Development Studio) to create the DTSX packages and SSIS which isn't available with SQL Express.
You also need Visual Studio to create WCF services, which it sounds like you already have.