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.
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?
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.)
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)
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?
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..?
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
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?
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.
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...
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.
- Proposed as answer by Jason Tontz Friday, December 11, 2009 12:36 AM
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
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!?
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 SERVERNAME.LIBRARY1.FILE1 as I2
left outer join SERVERNAME.LIBRARY2.FILE2 as C1
on JOIN CONDITION
left outer join SERVERNAME.LIBRARY3.FILE3 as M1
on JOIN CONDITION