• I have created SSIS packages to move data utilizing OLE-DB with an iSeries box.

    The packages runs fine in the Integration Services Project but when I import the packages to the server it fails with:

    Error: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component.

    Any help would be appreciated.


    We are running SQL Server 2005 Enterprise Edition with SP 2A.

    Friday, May 25, 2007 8:36 PM


  • Make sure that SSIS is actually installed on that server and that you have SSIS installed (Developer edition, preferably) on your workstation.
    Friday, May 25, 2007 8:46 PM

All replies

  • Make sure that SSIS is actually installed on that server and that you have SSIS installed (Developer edition, preferably) on your workstation.
    Friday, May 25, 2007 8:46 PM
  • Thanks for the response.


    Yes, SSIS is installed on our clustered server, and BIDS is installed on my workstation.


    I am able to create packages and migrate them to the server, the packages  move data between SQL Server 2000 and SQL Server 2005.


    However, when I do the same thing with iSeries data I get the PRODUCTLEVELTOLOW error. We have iseries client access installed on the server. Do you know if there is anything out of the ordinary about the iSeries OLE DB provider?    




    Tuesday, June 12, 2007 4:05 PM
  • Right, well, which version of SSIS do you have installed on the server?  And on your developer machine?
    Tuesday, June 12, 2007 4:07 PM

    On the Server we have Enterprise Edition ....

    Integration Services 9.0.3042


    On the client machine I installed BIDS from the Enterprise Edition CD  ....  

    Microsoft SQL Server Integration Services Designer
    Version 9.00.3042.00




    Tuesday, June 12, 2007 6:17 PM
  • Can you double check that you have SSIS installed on your client machine?  That is, do you have the SSIS service listed in the services control panel?  (Doesn't have to be running....)

    I don't know any other reason why you'd get a product level too low message unless something like the above is true.  (You get the SSIS design-tool (BIDS) when you install an appropriate version of SQL Server, but that doesn't mean SSIS is installed.)
    Tuesday, June 12, 2007 6:22 PM
  • Steve,

    i am having this exact problem at the moment. did you ever get your issue with the DTS_E_PRODUCTLEVETOLOW error resolved? i am trying to use an ODBC connection to read DB2.


    any help would be greatly appreciated.


    THANK YOU! =)

    Friday, June 15, 2007 2:47 PM
  • I am not sure if you found a solution yet, however the issue is the version of SQL Server 2005 that you are using.  Features such as Fuzzy Lookup, Fuzzy Grouping, Data Mining, etc... are only available in SQL Server 2005 Enterprise Edition.


    You can check out the following page for more details (the SSIS stuff is at the bottom)




    Tuesday, October 2, 2007 1:05 AM
  • I'm getting related issue. We have SQL server Enterpise edition installed. We just recently installed the SP2. My package is running fine in SSIS but it is running in SQL agent job.


    Here are the following error is throwing up.


    Message: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component "Multicast" (685).

    Message: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component "Row Count"

    Message: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level is insufficient for component "Flat File Destination" (1265).


    Is there any work around on this issue?



    Friday, October 12, 2007 8:09 PM
  • mssqlatoz,
    Install SSIS.

    Verify that SSIS is installed by going to the Admin Control Panel and then to Services.  Look for the SSIS service.
    Friday, October 12, 2007 8:13 PM
  • I'm working on upgrade from 2000 to 2005, main problem is upgrade whole bunch of DTS to SSIS.. Having short time to convert packages plus having issues, which we never had in 2000 could postpone upgrade till next year, till everything is verified and tested after conversion...

    Anyway, I'm saving packages on SQL server and able to fire them as job step or using DTSRUN command locally.

    I need to make possible to run SSIS from applications, located in different places...otherwise error:

    DTS_E_PRODUCTLEVELTOLOW may result in failure of execution process..

    My understanding is: if package, saved on SQL server, can be run as a job or started locally, it should work same way, if called from outside, by application..

    Do I have to install BIDS everywhere as well..??? Or, as work around I have to fire job instead..?

    Why it's been design in such way..? It was great with 2000, when we could fire packages from anywhere basically by using command promt, even packages saved as files.. now it's impossible..Why Microsoft doing thing more difficult..?

    Wednesday, October 31, 2007 2:53 PM
  • DTS had a redistributable run-time. SSIS does not, and is licensed on a server basis. So, yes, you either have to call a job to run the package, or set up a service or similar application to run the packages if you want to use them remotely.


    Wednesday, October 31, 2007 4:09 PM
  • I had problem with Flat file source return the same error massage.


    I Misladed becaues i have SQL2005 64bit server and workstation with 32 bit.


    or because mismatch of components.


    To eliminate problems:


    I defined a new job on the server with single step and the step run the specified package.


    when running job - it run without error.


    try it to see if the problem solved


    Sunday, March 23, 2008 9:59 AM
  • phil,

    i am having the same problem, but i have checked and rechecked that SSIS is installed on the DB server. i can run the package from BIDS and i can actually go to the DB server, open up SSMS integration services and execute the package from there. it is when i connect to integration services from any other computer or my workstation that i get this error. could it be something else?
    Thursday, May 22, 2008 12:44 PM
  • When you connect to Integration Services on the server by running SSMS from your desktop, and choose to run a package, you are actually executing the package on your local machine, not on the server. So you would have to install SSIS on the local machine.


    One way to avoid is it to create a SQL Agent job on the server, and start the job to run the package. This causes it to be executed on the server.


    Thursday, May 22, 2008 1:19 PM
  • I was not waiting for solution, instead I made stored proc which is fire SSIS by name, it executed locally on SQL server(we have there SSIS as well) so users are happy with this solution.. Having job - is for something routine, but to be flexible -stored procedure is works for us..

    I have this stored proc working on SQL 2000 and SQL 2005, so users can fire DTS or SSIS, depending which server they use(stored proc check it) and after conversion applications should work using this method...

    Thursday, May 22, 2008 3:46 PM
  • well this is setup in such a way that the automation software is installed on the app server and with dts it just executed the command line package. i will get the dba to install ssis on the app server as well and see if that fixes our problem.

    Thursday, May 22, 2008 7:19 PM
  • Wondering why my posting was not saved here..

    Anyway, I have a stored proc which is fire SSIS packages (passed as parameters) and this is working on SQL Server(SSIS is here as well), so for now I have this problem solved for my users..


    Thursday, May 22, 2008 7:27 PM
  • I am having the same problem and have confirmed that the SSIS service is running on my server.  What else can I check to try and resolve this problem?




    Monday, August 25, 2008 6:36 PM
  • I am having similar issues, but one thing I did notice is that SSIS is not running on the SQL Server.  We installed SSAS, SSIS, SSRS and our SQL Server on 4 different machines.  SQL Server is a cluster of two physical machines, SSIS is a VM server as is SSRS.  SSAS is a separate physical machine.

    SSIS is running as a service on SSIS machine, but not on SQL Cluster.  Is that an issue?

    We had a consultant suggest we have separate machines for them all, but I don't understand why.  I'm deploying a package from VS2005 and ive tried several ways with no luck.  I have moved it to SSIS Package Store, then signed onto SSIS in SQL Management Studio and executed it fine.  When I try to schedule it, that's where everything goes wrong.

    Any ideas?
    • Proposed as answer by Jason Tontz Friday, December 11, 2009 12:36 AM
    Monday, February 9, 2009 8:10 PM
  • I have discovered that you must run it from a SQL Management Studio connection to integration services on a server with Integration services installed. You cannot connect from a workstation where only the client tools such as BIDS and SQL Management Studio are installed, connect to the server which has Integration Services installed and run an SSIS job. I verified this on a workstation with that very setup with a DTSX package on a network drive. Same error DTS_E_PRODUCTLEVELTOLOW. I then RDP'd to the server to which I was connecting and ran the exact same DTSX package and it ran with zero errors.
    Hope this helps.
    • Proposed as answer by Jason Tontz Friday, December 11, 2009 12:41 AM
    Friday, December 11, 2009 12:41 AM
  • I had the same error when attempting to start SSIS packages programmatically from my web server. Besides Workstation Components, on my web server, I had to install Integration Services.

    Wednesday, April 21, 2010 3:56 PM
  • Can we get the error message spelling fixed too?  It should say DTS_E_PRODUCTLEVELTOOLOW
    Wednesday, November 24, 2010 11:01 PM
  • Is the dtexecui utility available without SSIS being installed on the machine?

    In my case, the package is stored in a windows folder and I am trying to execute it from the same machine. I checked among the services and did not find Integration Service listed there. But when I double click the package, it is opened with dtexecui and fails with the DTS_E_PRODUCTLEVELTOLOW error after executing a few of the tasks like 'Exec SQL task'. Just trying to understand how it can go that far without SSIS installed on the machine!?


    Friday, July 22, 2011 10:53 AM
  • To extract data out of DB2, you can use an "open query statement" over a linked server. You can even do joins into it.  here is an example  syntax. You cannot do where clauses that have conditions with text, as the ' that need to be placed around the text values will break the openquery statement.

    Works nicely. and you can schedule a periodical select/insert and create a mimic table in SQL with your 400 data, synchronized every so and so.


    create view XYZ as


    * from



    left outer join SERVERNAME.LIBRARY2.FILE2 as C1

    left outer join SERVERNAME.LIBRARY3.FILE3 as M1


    Tuesday, January 31, 2012 4:45 PM