SSIS - DTS_E_PRODUCTLEVELTOLOW Error
I have created SSIS packages to move data utilizing OLE-DB with an iSeries box. The packages runs fine in the Integration Services Projectbut when I import the packages to the server it fails with: Error: SSIS Error Code DTS_E_PRODUCTLEVELTOLOW. The product level isinsufficient for component. Any help would be appreciated. We are running SQL Server 2005 Enterprise Edition with SP 2A.
May 25th, 2007 11:36pm

Make sure that SSIS is actually installed on that server and that you have SSIS installed (Developer edition, preferably) on your workstation.
Free Windows Admin Tool Kit Click here and download it now
May 25th, 2007 11:46pm

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 anythingout of the ordinaryabout the iSeries OLE DB provider? Thanks. Steve.
June 12th, 2007 7:05pm

Right, well, which version of SSIS do you have installed on the server? And on your developer machine?
Free Windows Admin Tool Kit Click here and download it now
June 12th, 2007 7:07pm

On the Server we have Enterprise Edition .... Integration Services 9.0.3042 On the client machineI installed BIDS from the Enterprise EditionCD .... Microsoft SQL Server Integration Services DesignerVersion 9.00.3042.00 Thanks. Steve.
June 12th, 2007 9:17pm

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.)
Free Windows Admin Tool Kit Click here and download it now
June 12th, 2007 9:22pm

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 usean ODBC connection to read DB2. any help would be greatly appreciated. THANK YOU! =)
June 15th, 2007 5:47pm

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) http://msdn2.microsoft.com/en-us/library/ms143761.aspx
Free Windows Admin Tool Kit Click here and download it now
October 2nd, 2007 4:05am

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? Thanks
October 12th, 2007 11:09pm

mssqlatoz,Install SSIS.Verify that SSIS is installed by going to the Admin Control Panel and then to Services. Look for the SSIS service.
Free Windows Admin Tool Kit Click here and download it now
October 12th, 2007 11:13pm

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 couldpostpone 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 fromapplications, locatedin 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, ifcalled from outside, by application.. Do I have to installBIDS 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'simpossible..Why Microsoft doing thing more difficult..?
October 31st, 2007 5:53pm

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.
Free Windows Admin Tool Kit Click here and download it now
October 31st, 2007 7:09pm

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
March 23rd, 2008 12:59pm

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?
Free Windows Admin Tool Kit Click here and download it now
May 22nd, 2008 3:44pm

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.
May 22nd, 2008 4:19pm

I was not waiting for solution, instead I made stored proc which is fireSSIS 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...
Free Windows Admin Tool Kit Click here and download it now
May 22nd, 2008 6:46pm

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. thanks!
May 22nd, 2008 10:19pm

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..
Free Windows Admin Tool Kit Click here and download it now
May 22nd, 2008 10:27pm

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? thanks
August 25th, 2008 9:36pm

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?
Free Windows Admin Tool Kit Click here and download it now
February 9th, 2009 11:10pm

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 andran the exact sameDTSX packageand it ran with zero errors.Hope this helps.
December 11th, 2009 3:41am

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.
Free Windows Admin Tool Kit Click here and download it now
April 21st, 2010 6:56pm

Can we get the error message spelling fixed too? It should say DTS_E_PRODUCTLEVELTOOLOW
November 25th, 2010 2:01am

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!?
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 6:59am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics