Error in ADO.net-Destination after installation of an OracleClient, using ado.net-sqlclient
Hello, i got a big problem with using the ado.net-destination in my dataflowtask after installation of oracleclient11ghome. Following Error appears after executing: Information: 0x4004300A at Data Flow Task, SSIS.Pipeline: Validation phase is beginning. Error: 0xC0208457 at Data Flow Task, ADO NET Destination : Failed to get properties of external columns. The table name you entered may not exist, or you do not have SELECT permission on the table object and an alternative attempt to get column properties through connection has failed. Detailed error messages are: Exception has been thrown by the target of an invocation. Failed to convert the schema table obtained by querying the connection to a standard format. -------------- Before the OracleClient was installed, all was running fine. Permission are set correctly, and i installed all .net-frameworks new without taking effects on my problem. Does anybody know such a problem, or can help with finding a solve? I spent hours in this error, and now i use an OLE-DB destination temporarly, but its too slow. Best regards
November 13th, 2010 11:20am
What was the reason for this installation? If you create a UDL (to test the connectivity) would it connect?Arthur My Blog
November 13th, 2010 7:09pm
The reason for installation was that other people who develope on this server,too need that client to connect their data... If i create a UDL, all seems to be ok, i got all input and output colums listed in the ado.net-destination-object-properties, but on execute he gives out that error. The problem appears on the easiest ado.net-dataflows (such as import a table to a new one in the same database). With OLE-DB all works fine, i spent the last 5 hours to bring the performance with that objects from 10 hours executing time to 10 minutes :-) (with ado.net sqlclient it was at about 2 hours, with the new logic it can be under 10 minutes, i think). So my performanceproblem is solved, but i can still not use the ado.net-provider on that server... Can i debug such a process deeper, to get more detailed information about the error (perhaps with SQL-Server Profiler)? For any ideas i would be very grateful.
November 13th, 2010 10:56pm