FTP dial up and xml file download (1 Viewer)

Wysy

Registered User.
Local time
Today, 01:14
Joined
Jul 5, 2015
Messages
333
Hi,
I am struggling with a code to connect to an FTP server and download an xml file. I have this that worked on WIFI for a while but it fails to operate by now...The code is as follows:

Option Compare Database
'ftp download code
Private Const FTP_TRANSFER_TYPE_UNKNOWN As Long = 0
Private Const INTERNET_FLAG_RELOAD As Long = &H80000000

Private Declare Function InternetOpenA Lib "wininet.dll" ( _
ByVal sAgent As String, _
ByVal lAccessType As Long, _
ByVal sProxyName As String, _
ByVal sProxyBypass As String, _
ByVal lFlags As Long) As Long

Private Declare Function InternetConnectA Lib "wininet.dll" ( _
ByVal hInternetSession As Long, _
ByVal sServerName As String, _
ByVal nServerPort As Long, _
ByVal sUsername As String, _
ByVal sPassword As String, _
ByVal lService As Long, _
ByVal lFlags As Long, _
ByVal lContext As Long) As Long

Private Declare Function FtpGetFileA Lib "wininet.dll" ( _
ByVal hConnect As Long, _
ByVal lpszRemoteFile As String, _
ByVal lpszNewFile As String, _
ByVal fFailIfExists As Long, _
ByVal dwFlagsAndAttributes As Long, _
ByVal dwFlags As Long, _
ByVal dwContext As Long) As Long

Private Declare Function InternetCloseHandle Lib "wininet" ( _
ByVal hInet As Long) As Long

Sub FtpDownload(ByVal strRemoteFile As String, ByVal strLocalFile As String, ByVal strHost As String, ByVal lngPort As Long, ByVal strUser As String, ByVal strPass As String)
Dim hOpen As Long
Dim hConn As Long

hOpen = InternetOpenA("FTPGET", 1, vbNullString, vbNullString, 1)
hConn = InternetConnectA(hOpen, strHost, lngPort, strUser, strPass, 1, 0, 2)

If FtpGetFileA(hConn, strRemoteFile, strLocalFile, 1, 0, FTP_TRANSFER_TYPE_UNKNOWN Or INTERNET_FLAG_RELOAD, 0) Then
Debug.Print "Success"
Else
Debug.Print "Fail"
End If

'Close connections
InternetCloseHandle hConn
InternetCloseHandle hOpen
End Sub

Then i have form with a command button:

Private Sub Command0_Click()
'ftp download file location and name
FtpDownload "\xxxxxx.xml", strName, "ftp.xxx.com", 21, "username", "password"
End Sub

It worked on another network but it fails now. I have checked the ftp server by manually downloading the xml file at it is up and works. Any idea?
thanks
Andrew
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:14
Joined
Feb 28, 2001
Messages
27,001
In summary, you are telling us that this procedure used to work but now does not. At what point does it appear to fail? At that point,is an error raised or does it just tell you that it didn't work or does it do nothing? Or how do you know that it failed? (OK, obviously it doesn't get the file... but was there another reason to know it failed?)
 

Wysy

Registered User.
Local time
Today, 01:14
Joined
Jul 5, 2015
Messages
333
I did this code at my work place using that internet. Went home, connected to my home network and issue came:
it makes the defined destination file with 0kb and does not download the whole file
 

static

Registered User.
Local time
Today, 08:14
Joined
Nov 2, 2015
Messages
823
That's a lot of code. Did you try httprequest?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:14
Joined
Feb 28, 2001
Messages
27,001
OK, let's define some terms I have to use to explain what is happening.

When you do this, your local copy of FTP is the client; on the server, the most likely name for the server image is either FTPD or FTPServer. When you run FTP (client), it is the part that not only establishes the connection to your partner server, it also interacts with the local file system because the file at the server end doesn't even have to be Windows based. (Could be UNIX, e.g.) So to hear that the file was created locally simply means you got far enough in the process to establish a handshake, and the client prepared a local "repository" for what it was expecting to get from FTPD/FTPServer.

BUT... after the initial handshake, something went wrong, so FTP and FTPD agreed to stop talking. They left behind the file without putting anything in it, but that is actually a good sign. It means that you got far enough to have the handshake before things went south on you.

There are many ways to find out just what went wrong. All of them involve capturing a log file. I'll describe the methods as clearly as I can.

The FIRST place to look is from Start >> Control Panel >> Administrative Tools >> Event Viewer. You need to attempt a transfer and IMMEDIATELY note the time on the task bar clock. Getting this within one minute will be close enough. Then get into the event viewer using the path I described and see what logs are available to it.

Browse through the logs to the approximate time of the transfer attempt and see if ANY of the logs records an error or even a warning. There should be a network log available to Event Viewer, but the system logs for that time can also be informative. If it was a device error, there might be a driver log, but to be honest, I'm not betting on that.

IF this is a TCP/IP handshake violation, typical network errors for things that comply with TCP/IP standards will be three-digit numbers; 1xx is INFO, 2xx is SUCCESS - but you might see something starting with the digits 3, 4, or 5 - if the error occurred in the handshake as a protocol violation or connection error.

If the error was in the file system due to space, permissions, or some other procedural error with respect to the local file system, then the error code will be some sort of hexadecimal value that starts with "0x" and is followed by 8 hexadecimal digits. Most commonly, the first digit after the "0x" will be 8, but beyond that it becomes tricky to predict.

You might also search the system using your Windows Console commands or the File Search system to find a file, probably on the C: drive, that contains FTP in the name and is of file type .LOG, which also might be useful. If such a file exists, you can use the Notepad utility to read it. Again, scan through the timestamps to find the time of the transfer. See what errors occur within no more than one minute either way from the time of the attempted transfer.

If that doesn't work, see if you can find documentation to allow you to change the logging level on your FTP operation. You might find a CONFIG.FTP or an FTP_CONFIG.(no file type) file that would allow you to set a DEBUG parameter to a value other than 0. If so, I recommend 5. You might also / instead be able to set VERBOSE to YES. Edit the file and try the transfer again.

The log file should also work with Notepad. DO NOT CHANGE ANYTHING ELSE in that file. Further, once you get an answer to this problem, restore the file to its original content. Because when you turn on DEBUG to 5, you WILL create a log file SOMEWHERE and it won't be small. You don't want FTP debug logs filling up your disk, and they WILL do so very easily.

In any case, near the end of the log file, start reading from the bottom up. You should find events that describe "dissolving" or "releasing" the connection. Maybe only a dozen or so lines earlier than that, you will see the detailed handshake and will see the error that aborts the handshake.

It will be tough reading, but the important thing to remember is that when an error occurs in one of these transfers, the log very quickly shuts down. So you might have 10, 20, or 30 lines before the end of the file. Maybe more, but I have always found that the critical error is pretty close to the end of the file.

In ANY of these efforts, your goal will be to find an error code that tells us WHY the transfer started but then stopped. Without that info, we go nowhere.

Before you ask, my job with the U.S. Navy (before I retired) involved nursemaiding a system that used batch-mode FTP jobs to transfer files from my assigned machine to or from over 15 different machines, each with a different version of FTP, different vendor, different version number... and every so often they upgraded, forcing yet another round of FTP debugging. Reading FTP logs to find handshake errors is NOT pleasant and NO, do not send them to me. I'll puke if you do, and my wife already says my carpet stinks.

Try to read the logs as I suggested, from the bottom up. Take your time. You'll get the hang of it. But actually, if the system network logs (via Event Viewer) turn up something before you have to resort to forcing FTP logs, you should be thankful.
 

Wysy

Registered User.
Local time
Today, 01:14
Joined
Jul 5, 2015
Messages
333
Thanks a lot, i will get myself through it.
Does it however mean that the code itself is ok? Can it be that temporarly the server has been changed? With the given credentials i am able to connect and download the xml file via total commander, browser and ftp network connection in explorer. However i am not able to connect via filezilla.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:14
Joined
Feb 28, 2001
Messages
27,001
Does it however mean that the code itself is ok?

Maybe, maybe not. But it is very close.

Can it be that temporarly the server has been changed?

Maybe, maybe not. More likely, the connection path has changed so the issue might be security related. E.g. firewall rules, remote vs. local security profiles, something wrong in your FTP_CONFIG file (which is machine-specific), ... who knows?

The only way to know what happened is to find one of those error codes. Dissecting a log file is a method of last resort. Finding an extant entry in a system-based log file would be preferable ('cause it is easier to get to.) But without an error code to specify what went wrong, neither question can be answered definitively.
 

Wysy

Registered User.
Local time
Today, 01:14
Joined
Jul 5, 2015
Messages
333
Unfortunately i did not find any log about this until now. But what i have experienced is that it might have something to do with passive mode of ftp. I have reconstructed the code: with giving false user/password combination the destination file does not even show up. With correct user/password combination an xml file shows up in the destination directory but does not download itself. So connecting to the server seems to be working.
 

Users who are viewing this thread

Top Bottom