This content has been marked as final. Show 2 replies
Devious (love the name btw),
I've never tried using the DatabaseOperation transformation from any other adapter type than a Database Adapter, so I don't know if this is causing the problem. I'm unsure as to whether the Bridge code of the adapter is used to perform this type of transform. However, if so, the ftp bridge does not know how to connect via JDBC or SQLNet. I may be barking up the wrong tree on this however, but it would seem reasonable?!?.
Two things I'd try.
1. Create another DB adapter / use an existing DB adapter and try the same transform on that. This should prove or disprove the above theory.
2. Increase your "retry count". I think it is set to "1". Increase it to 5, and have a "retry delay" of "5".
It's a good theory but I don't believe that's the problem. There are a couple of things I have tried which may help.
Firstly, I have retained the transformation in the ftp adapter but changed the connection data to point at another Oracle database. This time I am able to get a JDBC connection. Incidentally, the hub, adapter and target database are all now hosted on the same server whereas they weren't before (the target was a different server). I believe both databases are at the same version (need to verify) but it could be that JDBC connections are prohibited by the target database. If you have any thoughts on that I'm listening.
Secondly, if you take a look at an FTP adapter start script the classpath contains the same jar files as that of the db adapter, plus additional ones. That says to me that if the db adapter can do it, the ftp can too. Plus, I haven't seen any text indicating a restriction on the use of this transformation.
In summary, all this appears as though we won't take advantage of the transformation and I'll end up using an alternative, but I still have your suggestions to try offline.