The 1st connection connects fine and the transfer occurs using passive FTP. If the application connects again and tries to send another file it appears as though it tries to send it using active FTP instead of passive. This one fails with a 425-Can't open data connection. There's nothing changing the .lPassiveFTP property to .F., so I'm not sure what could be going on. I'm attaching a server log so you can see what I'm seeing. The PORT command only occurs on the 2nd connection. The code running both of the sessions is the same. I can't figure out why there's a difference. Any help would be appreciated.

003049)1/20/2014 21:19:53 PM - (not logged in) (72.73.200.1)> Connected, sending welcome message...
(003049)1/20/2014 21:19:53 PM - (not logged in) (72.73.200.1)> 220 #
(003049)1/20/2014 21:19:53 PM - (not logged in) (72.73.200.1)> USER sampftpuser
(003049)1/20/2014 21:19:53 PM - (not logged in) (72.73.200.1)> 331 Password required for sampftpuser
(003049)1/20/2014 21:19:53 PM - (not logged in) (72.73.200.1)> PASS ********
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 230 Logged on
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> TYPE I
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 200 Type set to I
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> PASV
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 227 Entering Passive Mode (194,74,253,164,245,135)
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> STOR temp\RP19K9KM.DBF
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 150 Connection accepted
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 226 Transfer OK
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> TYPE I
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 200 Type set to I
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> PASV
(003049)1/20/2014 21:19:53 PM - sampftpuser (72.73.200.1)> 227 Entering Passive Mode (194,74,253,164,245,136)
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> STOR temp\RP19KD4K.DBF
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 150 Connection accepted
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 226 Transfer OK
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> TYPE I
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 200 Type set to I
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> PASV
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 227 Entering Passive Mode (194,74,253,164,245,137)
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> STOR temp\_3ZA19K414.ZIP
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 150 Connection accepted
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> 226 Transfer OK
(003049)1/20/2014 21:19:54 PM - sampftpuser (72.73.200.1)> disconnected.
(003050)1/20/2014 21:20:22 PM - (not logged in) (72.73.200.1)> Connected, sending welcome message...
(003050)1/20/2014 21:20:22 PM - (not logged in) (72.73.200.1)> 220 #
(003050)1/20/2014 21:20:22 PM - (not logged in) (72.73.200.1)> USER sampftpuser
(003050)1/20/2014 21:20:22 PM - (not logged in) (72.73.200.1)> 331 Password required for sampftpuser
(003050)1/20/2014 21:20:22 PM - (not logged in) (72.73.200.1)> PASS ********
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> 230 Logged on
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> TYPE I
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> 200 Type set to I
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> PORT 10,211,55,3,195,150
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> 200 Port command successful
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> STOR temp\RP19QIUD.DBF
(003050)1/20/2014 21:20:22 PM - sampftpuser (72.73.200.1)> 150 Opening data channel for file transfer.
(003050)1/20/2014 21:20:32 PM - sampftpuser (72.73.200.1)> 425 Can't open data connection.
(003050)1/20/2014 21:21:03 PM - sampftpuser (72.73.200.1)> 421 Connection timed out.
(003050)1/20/2014 21:21:03 PM - sampftpuser (72.73.200.1)> disconnected.

Here's more info:
http://www.west-wind.com/wconnect/weblog/ShowEntry.blog?id=898

There are a couple of workarounds... hopefully Microsoft will get this addressed, but so far the response has been non-existant. And yes it sucks that they basically broke a core OS component.

+++ Rick ---

I'll look into using FTPSendFileEx2 and giving an automated graphic that runs until the upload is finished.

The problem for me isn't keeping the connection open in between transfers. The problem occurs when I connect, send, close connection and then connect and send again. My processing takes a while, for instance to make a backup so I check the connection before the backup and then close while the backup is being done. I don't want to go through the backup process if I can't connect, so that's why I check it on the front end.

-Phil

Ten years later... I ran into a problem that I believe is related to this. For me, after the first FTP connection, the firewall dialog pops up to allow the connection. I am using an old version of wwFTP (I really should upgrade), so maybe this was addressed a long time ago. In case it helps anyone, I believe this is the offending code within FTPConnect():

IF THIS.lPassiveFTP
   THIS.nServiceFlags = THIS.nServiceFlags + FTP_CONNECT_PASSIVE
ENDIF

It looks like THIS.nServiceFlags gets incremented with each call to FTPConnect() -- and I don't see it being reset anywhere else -- so passive mode is set properly only on the first call. I reset nServiceFlags to zero after calling FTPClose() and my problem went away. Reinstantiating wwFTP for each connection should work as well.

In the last version of Client Tools and Web Connection we've switched to a new FTP client (.NET Based) that doesn't deal with all the Windows IP interfaces (which for FTP are very awkward and incomplete). The new client defaults to passive FTP - there should be no reason to ever use active FTP as that's unlikely to get through any firewall on either end.

As to this:

THIS.nServiceFlags = THIS.nServiceFlags + FTP_CONNECT_PASSIVE

that's still in the last versions. The idea with wwFtp was always that you use 1 instance per connection. Once you close you use a new instance.

In hindsight it would have been better to have base service flags and then have a working set that gets updated. Also that should be an Bitwise OR operation - at that time that wasn't available in the language, so used additive instead.

THIS.nServiceFlags = BITOR(THIS.nServiceFlags, FTP_CONNECT_PASSIVE)

IAC - that component is now deprecated and the new class is wwFtpClient which has mostly the same interface but uses the .NET component under the covers.

Class wwFtpClient

+++ Rick ---