[DTS.Pipeline] Error: The product level is insufficient for component "Derived Column" (408).
I get a similar error for the SCD and OLEDB Dest components. The control flow item works fine, it is the data flow components that have the problem.
Anyone else have a similar issue?
-Evan Black
Evan, this is similar to other issues we've seen in the past with SKU differentiation. Will you please file a bug and include the packages if possible? We'll take a look.
Make sure you include information about your setup, what versions were previously installed etc. This sounds like it may be a corrupted setup issue.
Thanks,
K|||Wandering if there is a solution to this? I am having the same issue with executing an SSIS package from code. Package loads, properties are accessable, but execute returns
The product level is insufficient for component "Scorecard Source CSV"
I have VS 2005 RC1 and Sql Server 2005 CTP installed|||Any resolution/update to this? Getting the same error when attempting to automate via DTEXEC & DTEXECUI|||Never saw it before today; but this was the first time I ran from "debug|start w/o debugging"... it opens a command window and the first ten or so containers err with this message.Any resolution?
Running VS RC1 and September SS 2005|||Have you installed SSIS, or just the workstation components? If later, the package will run fine in designer/debugger, but most tasks would not run outside of designer.
SSIS ships as part of SQL 2005, but the setup give you a choice of whether to install it or not.
Please rerun the setup. In one of the first screens the setup program asks which components to installs, there are 5 checkboxes total: SQL/SSAS/SSRS/SSIS and Workstation components. Please make sure the SSIS check box is checked.
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=110020|||
This is probably the reason for the error. The full Visual Studio 2005 product and the SQL Server 2005 tools ONLY have been installed on this XP box. The database is on a 2003 Advanced Server... and a Sybase ASA data source on another.
Thank you... I will test the external execution of the package on a different host.
But let me vent a bit here now.... while the answer is a good one, and seems like it might just be the right explanation for this issue, the solution (as a general solution to a problem) is not a good one for us...
This is currently somewhat of a controlled environment with Ghosting taking place at various stages along the way. We are trying to develop in a way that simulates our product deployment. We have two medical devices that each run Sybase ASA (and two schema versions of one, and three schema versions of the other), and we are replicating those five schemas into one staging area where we are picking up data with SSIS and transforming it (ETL) into a snowflake within SQL Server which could possible be our reporting solution for the next ten years or so - IF THINGS WORKED! There have been roadblocks ever step of the way though, as much as people are raving about SSIS, SSRS and SSAS (OLAP)... the products just do not perform as anticipated and reported. Stumbling blocks? We can not currently read data from ASA when the replication server is on a different subnet. This is because in order to get from one subnet to the next the ASA connection must include the parameter "commlinks=tcpip" and we have found no way to include this in the string. Perhaps a Sybase issue (aside from the fact that Sybase tools don't have the problem and VS 2003 as well as 2005 do, so not a beta issue either); but Sybase is working on it for us. And our SQL Server database does not reside on the developer's box, only to find out later that SQL Sever Destination do not currently work with anything except a "local database"... after weeks of working with it, and around it....
We constantly have problems with packages just breaking and not being fixable, with the only solution being to rebuild the package from scratch... for instance, today, after five or six days dealing with null values in a containers failure path (the four columns being correct in the success stream and two being null in the failure stream) we discover that there are no "outputs" in the advanced editor for that container. It lets us add them; but the data types are empty and it warns us of that... but when we try to change them (they do change) and save them, it errs with "you cannot change the data types" on this element. At one point I tried to delete the error elements (hoping to fool the tool) and it would not let me; but it let me rename them to my output's names... and then it also would not allow me to change the data types from int4 to what I wanted (string). Anyway, the only solution was to start a fresh package and build it correctly from the beginning.
And it was during this tedious debugging process that the "debug | run without debugging" was discovered and this new error was found.
but we have been dealing with installation and configuration issues for three months now - and while I have been the primary, full-time developer/DBA doing so, there have been a team of others (sometimes as many as ten) doing the same thing, and experiencing the same problems - including an onsite, fulltime Microsoft employee who is on the premises doing WebPieces demos for our evaluation could not use SQL Server 2005 (September) for a database (using Access instead) because he "could not get it installed".
I have spent six full-time weeks, first with April, then with June CTPs... and finally with September doing NOTHING but installation, cleanup, start-overs, and reinstallation on various platforms... and another six weeks struggling with SSIS.
The final position being taken that none of the uninstallation or clean up tools work properly and the ONLY way to do the installation is to do fresh OS installs... Ghost, and be prepared to start over - frequently.
But even this is tedious by the time you get the other (even minimal) pieces you need installed (antivirus, spam blocks, tools) and installed in the domain, etc. It all takes time...
and the "fix" to every new problem cannot be "run install and make sure you did"... whatever. I mean, I know that this is valuable advice for some people, and for some circumstances; but it is not an acceptable solution.
The latest major change in direction has been to eliminate the external data source in replication server, add Sybase "direct connect" and replicate straight into SQL Server into a relational store (as a staging area), and then use SSIS to transform into the reporting database (star, actually modified star, snowflake).
This gives us the added advantage of allowing us to slowly migrate a subset of the 400 existing Crystal Reports from an operational store to the new tools - so instead of providing just a prototype/demo model in January, we are giving them a platform that can evolve... but, again, ONLY IF IT WORKS!
Having to change strategy this late in the game - three months into a six month prototype - is NOT a good thing.
Did I mention I have heartburn?
Thanks again for your response... and listening to my pain :)
No comments:
Post a Comment