Push FTP

  • Can someone point me in the direction of a com dll I can purchase to do the same thing.  Or perhaps post some code I can use to get started.  I have 36 remote SQL servers that I would like to bring data in house with.  Error and failure data is important.  We do not have a managed network so over the web is my best bet.

  • I've mostly sent small files over a short WAN (3 hops), so I haven't seen any issues with performance. The largest files were 10's of MB, so not huge stuff. Error recovery isn't really there, this is more like sending via UDP.

    I know this isn't the best ftp object to use, even the ones with IE don't seem to perform great.

    I might check on a VB or .NET forum and ask what people are using there. They've probably had experience with something, which is what you need in a recommendation.

  • Steve,

    Great Article!

    I would like to comment on the Darren Green's error checking question here. As I replied in the discussion for my article Tuesday when asked the same question: "The solutions here are a Proof-Of-Concept" . One has to implement their own error checking solutions based on their own requirements. As an idea I suggest what works for me. I use it in Pull FTP but it easily could be used the same way in Push FTP.

    1. Get the file sizes and /or file names - whatever you like with FileSystemObject.

    2. Do DIR on the remote FTP directory to a local text file. Parse the file using VBscript.

    3. Compare file sizes /file names from Step 1 to Step 2. If they are not the same, send an SMTP email to operator.

    STEP 1  - DOS command, STEP 2 and 3 - VBScript. If you need to switch from DOS to FTP and back:


    strCommand = "mycommand.bat"

    strStyle = 1

    StrWait = False

    Set sh = CreateObject("WScript.Shell")

    ReturnCode = sh.Run(strCommand, strStyle, strWait)


    start /wait C:\windows\system32\ftp.exe <my FTP parameters here>



    start /wait C:\windows\system32\ftp.exe <my FTP parameters here>

    cscript myVBScript.vbs


    Regards,Yelena Varsha

  • Ya know, there are always two ways of looking at a problem.  One person's push is another's pull. 

    Another version of the solution is to have server A publish the bak files to a directory configured for http://ftp.&nbsp; Then use the DTS FTP get task from server b to pull on a schedule.   Kinda sounds like snapshot replication.

    Course, setting up a Web Service to dump the tables might be easier now adays.  Truncate Development / Import from Production...  And in Sql Server 2005, that becomes a lot easier...

    Charley Jones
    A+, ITIL, MCAD, MCDBA, MCITP: Sql Server 2005 Adminstration, MCT,
    MCTS: Sql Server 2005, MCP, MCSA, MCSE, MOUS, PMP
    President and Founder S3oLV.Com: Sql Server Society of Las Vegas
    President and Founder LVXUG.Com: Las Vegas XNA Users Group

  • Good article. 

    For additional thought, before tossing aside a third-party component solution due to cost and complexity consider this, based on your salary what did it cost you to create this solution?  Did you document it well enough for the process to survive you without disproportionate maintenance cost?  Don't forget to include all aspects of your time including, planning, researching, documenting, and testing plus estimating the cost of implementing robust error reporting.  Also, if this process fails what about retry attempts.  Both the error reporting and multiple retries are available with many FTP component packages. 

    The larger downside of your solution is the lack of resuability.  If you had something else come up that could use this FTP code, you would have to cut and paste or rewrite it both of which would increase your total cost of ownership.

    All of that said, your article has obviously adressed a large community of readers and provoked a lot of good conversation. 

    Good job!

  • using CLR procedure, much more secure,robust free and extensible solution here



Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply