July 14, 2008 at 8:32 am
I am running a reasonably straightforward SSIS package, pulling from a flat file, parsing and separating records, then writing them to storage tables.
When I open the package in design it looks good, no warnings or errors. I can open the control in the dataflow, I can preview the table to which records should be written. When I execute the control flow task, it starts performing lookups, then reports:
Error: SSIS Error Code DTS_E_OLEDBERROR, an OLEDB error has occurred. Error Code 0x8007000E.
Error: Unable to retrieve column information from the data source. Make sure your target table in the database is available
Error: Component "OLE DB Destination" (24082) failed the pre-execute phase and returned error code 0x020204A.
The same package has worked on two other systems. All systems involved have the same SP and version.
July 14, 2008 at 2:37 pm
Then definately as it says it can not find the destination table. Just make sure you are not dropping the table anywhere else. You can also use a data viewer to see the data coming in.
-V
July 14, 2008 at 2:42 pm
Are you using the same table elsewhere in the package? It could be the table is locked by another process and SSIS is being denied access.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
July 14, 2008 at 2:58 pm
Thanks for your ideas.
The table is not being deleted at any point in the process, nor has it been accessed by any other processes at this time; I am executing a data flow task from the control flow pane, using right-click => execute task.
I added a data viewer not only to the input for that control, but also to the main input source for the data flow. Apparently because the task was failing during pre-execute, there were no data records displayed in either of the data viewers.
In design mode I can open the control (an OLE DB destination pointing at a SQL 2005 table) and preview successfully. In debug and when running the DTSX standalone, I get the error message noted above.
July 14, 2008 at 3:03 pm
well, u said like that package is executing with no errors on other systems. so, The problem might be u may not have exclusive access to the database. check the user privileges with the other systems where it is executing fine..
July 14, 2008 at 3:04 pm
I have made the mistake of using package configurations and forgot to change the path and or table name in the config and spent a while being frustrated the whole while.
July 14, 2008 at 4:38 pm
Alan and ssismaddi, thank you as well for your assistance.
The table involved is new, having been created specifically and exclusively for this process, so there are no other processes that are locking the table. I have tried runing it under an account that is sa on the database, so I am reasonably certain that permissions is not the issue.
I am still going through the config file very carefully; it works in other places but not here, and the config flie is what is different. THe problem is, I do not see any unexpected differences there, and it runs caches for several lookup controls successfully before it gets to this failure, so it appears to be able to hit the database correctly.
Right now I am considering pulling everything out and setting it back like it was before I started and starting over again.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply