Using ftp address in a macro

[John Norman]

Hi All,

We are currently trying to do a document comparison by comparing the
active document with a file on an FTP site. When doing manually,
everything works great, but when when I record the action, and attempt
to use the macro, we get Run-time error '5273'. The macro takes the
following form:

Sub Macro1()
'
' Macro1 Macro
' Macro recorded 12/2/2003 by NormanJD
'
ActiveDocument.Compare Name:="ftp://1.2.3.4/Compare/test.doc"
End Sub

(IP address changed to protect the guilty)

I have tried variations such as
"ftp://username[email protected]/Compare/text.doc" and have added the
FTP site along with username and password to the "Save as" list and in
"My Network Places" I am testing this in an environment with no
firewalls or proxies, (will add those later) but anonymous logins are
disallowed. My workstations will either be running Windows 2000 or
Windows XP with Office 2000 and all latest patches for both the O/S
and Office. I've played like crazy with IE settings, but don't think
this will help as it does wotk when I do everything manually, only the
macro fails...

Has anyone tried this or have a solution? Is this a VB/macro bug?

John Norman

 

[losmac]

I thing, the only way is to get file from ftp to local
drive (template folder) and then compare the files.

 

[Philip Herlihy]

You can take the FTP connection out of the equation by using webdrive
(www.webdrive.com) which maps an FTP server as a mounted drive. Then you
can use any software on your PC as if the file was local. Perfectly
marvellous. I use it for uploading websites using the industrial-strength
utility Robocopy (resource kits).

 

[Guest]

Trying to get the file from FTP using VBA could be tough,
an easy workaround I heard from a guy on this forum was to
write a quick batch file using ftp commands and the VBA
can Shell "yourBatchFile" to get the file to your local
drive, then do what you will with it.

 

[Malcolm Smith]

Even better, get an FTP control and embed it into your own application and
then that saves messing about with Shell statements and the like.

Also it will give one better control of various error events. For
example, if there is a poor connection and the thing starts to time out
it'll be easier to trap it within one's VBA code rather than hoping that
the Shell stops cleanly.

Just a thought.

- Malc
www.dragondrop.com