I think there may be a bug with TDA’s implementation of the Secure FTP Connection with Public key only (not Public + Password).
Despite setting the “Authentication” drop-down to “Public Key”, and supplying the “Private key file” in the appropriate place, testing the connection still prompts for a password (which in my case is blank). The test is successful, all is well.
But when I try to use that FTP connection in the Automation FTP step, it will not allow me to select any file operations because it says a password is required - despite having checked “Save password” on the connections property, and leaving the box blank when prompted and hitting ok.
We really need this feature, so if there’s a work around here or some way to get it to work, that would really be awesome.
Do you have any more information? We need to use this function come Monday to upload a client list to an external vendor, and this is the only option (SSH over FTP via Pub/Pri key) that we have to complete the transfer.
You could use the variable in an automation script in a find and replace. This file can then be used in the run command. The run command runs any command line util.
Yes, but so far as I know, there’s no built-in variable that captures the exported file name, and I haven’t figured out a way to define a variable that consists of both static as well as dynamic components (such as a static file name with a variable date).
The Toad automation Run program works very well with dynamic names. You can use it for any program that takes parameters in a command line argument by inserting #variable_name# where you need it. The run program has an argument line for where you would put the space and parameters (no space needed) after the program being executed. I used this to get around the problem of the Toad copy function causing a build error for a file that does not exist at run time but will exist later on in the job and has a datestamp added to the file name. I pass the dynamic file name to a batch job that I created. The Toad copy problem already has a CR and might be fixed in 3.2 but I am still on 3.1.
I don’t have access to a FTP server with this type of authentication to check out the current behavior of the TDP 3.8 but I’d suggest to use it because there have been several updates to the FTP.
I’m in TDP 4.3 and this is still an issue. Of note…I did get around it by setting it to Public Key + Password, putting random characters into the password field, setting it back to Public Key and saving.
Thank you Julie.
Your customer support is top-notch. I appreciate the attention you've given thus far and feel free to reach out if you need more information.