Database Search
If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.
TechHome
WinInet
 |
- !!NEWSFLASH!!
- !Limitations of the WinInet FTP Functions
- !List of Win32 Error Codes
- 12003 ERROR_INTERNET_EXTENDED_ERROR
- 12007 Error
- 12163 error trying to trying to open an FTP session
- Active vs Passive FTP Connections
- Allowing User to Accept Cookies
- Ascii vs Binary FTP Transfers
- Automating Web forms with Cookies
- Can WinInet Handle Framed Pages
- Change Phone Number of Connectiod-Ras entry
- Check for IE4
- Check if a File has been Modified on Web Server
- Check if FTP File Exists
- Check if iUrlOpen returns what your expecting
- Cookies Wont Go Through
- Delete Temporary Internet Files Cache
- Dialog Progress Bar not Working
- Download a Message directly to a Binary buffer
- Embed User Id and Password in URL
- Error 12045 Invalid Certificate
- Error 307 File Access Failed
- Error 321 iFtpFindNext failed
- Error code 632 on WinInet dial-up
- ERROR with iOptionSet
- FTP Directory Exist
- FTP File Exist
- Ftp Functions and OpenVms
- Ftp Issue with Large File Transfers
- FTP Keep Alive
- FTP Proxy Server and Passive Transfer
- FTP SSL
- FtpListFileNames UDF
- Get Wininet Error Description String
- Get Real Internet Address
- Get WinInet Error Description String
- Getting ERROR on iHttpOpen with HTTPS
- Handle Http Redirect
- How to Specifiy HTTP User Agent
- How to use iGetConState
- How to Use iHttpOpen - Do a Post - and Grab HTML
- HTTP and WinInet - An Opus
- HTTPDownload 1.4
- iBegin and Firewalls
- IE4 Dlls needed for Wininet Extender on 95
- iFtpCmd and MDTM command
- iFtpCmd and Quote Site
- iFtpCmd APPE Causes iWriteData to Crash using IE 7
- iFtpCmd APPE Example
- iFtpCmd Issues
- iFtpCmd RETR Crash on Windows 7 32-bit WinInet Only
- iFtpDirMake Error 318
- iFTPFileSize 300 Error FileOpen Failed
- iFtpFindInit Memory Leak
- iFtpFindInit Returns Zero
- iFtpFindInit Wildcards
- iFtpFindNext Problem with Date
- iFtpGet Newer Files Only
- iFtpGet to get INI file
- iFtpGet Wininet Error 12031
- iFtpPut Error 12002 ERROR_INTERNET_TIMEOUT
- iFtpPut Error 12003
- iFtpPut to Unix Server
- iGetConState Return Values
- iGetConState Returns False
- iGetConState(0) Returns 1 for No Connection
- iGetLastError Always Returns 2 with IE5
- iHostConnect and Return Codes
- iHostConnect Error 65535
- iHttpInit and 401 Error
- iHttpOpen Error 406
- iHTTPOpen Error Message 12044 ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED
- iHTTPOpen Not Returning 404
- Installation of a Certificate
- InternetCookieSetEx and InternetCookieGetEx
- iOptionSet Error
- Latitude and Longitude of An Address
- Logfile of FTP Session
- Make a WHOIS Request
- Multiple FTP Sessions
- Non Standard Port
- Post HTML Problem
- Print a Web Page
- Progress bar during HTTP download
- Removing Empty Directories with FTP
- Require Certificate for HTTPS Downloads
- Return Info on Web Server
- Sample code - Weather Watch
- Secure FTP Issues
- Select Links That Contain Java Script Code
- Syncronize FTP
- UrlEncode of Hebrew characters
- Website Forms with Viewstate and Eventvalidation
- Wininet and Cookies
- WinInet and JavaScript
- WinInet and OpenVMS Problem
- WinInet Errors
- WinInet Not Supported for Use in Services
- Yahoo Signin Form
Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.
Ftp Issue with Large File Transfers
Question:
I have had no trouble in the windows environment with the ftp extender until recently. Retrieving files from a windows ftp site, everything works fine on files 1MB or smaller, but now the 5MB files transfer, but the program gets stuck on receiving response from the server as the message shows on the progress dialog. Using DSL on both systems. Nothing has changed that I am aware of. There is no problem if the receiving machine is on the same network as the server. Just across the internet and only on large files. Any ideas?
Details:
wb ver:2005B
extender wwint44.dll ver: 40077
Systems on both end are highspeed DSL (means 384KB upload). 5MB file transfers show 100% on the progress bar and physically show up as readable files on the receiving server. However, the status message continues to show as receiving response. On the local intranet, all works fine.
Answer:
To reiterate the issue:You are successfully getting the file from the FTP server. But the problem you are having is with the iFTPDialog. The progress bar on the dialog is not updating correctly. Is this correct?
Something to consider:
You are using iFtpDialog "auto" option (3) and you are attempting to pass the file size retrieved from the function iFtpFindNext,
to iFtpDialog function, inorder to update the progress bar.
What if the line:
fSize = Itemextract(3,remote_srcfile,@TAB)Was NOT successfully grabbing the filesize. This could potentially confuse the iFtpDialog. Minimize the code to only that code which reproduces the problem you are seeing. Then add DebugTrace(@on,"trace.txt") to the beginning of the script, run it until it errors then post the resulting trace file here.
User Reply:
Here is what I have come up with after additional testing. Using a highspeed hosting site, the transfers NEVER fail to work when the DSL side also has a fast download speed. The site giving me fits has a slow DSL connection and it fails only on large downloads. At this point, I am going to ask the customer to consider upgrading the DSL connection because his other two locations have faster lines and they work without fail using the same code. Maybe this is not the software solution, but it is a solution to his problem.Answer:
Perhaps it is a time-based problem. Does the error occur at any specific amount of time after the download starts? Perhaps at a 5 minute point or something? The problem seems to be that transmission of data would just *stop* for a period of time greater than a tcpip protocol timeout period.User Reply:
The problem is a slow connection that just hangs on large files. I can easily pump 500 files of varying lengths & 300MB in total size no problem when both ends offer some speed. If one of them is slowing the connection down too much, they lose their grip. Line speed tests proved the line was slow. AT&T also ran tests and said the connection was running at dialup speed instead of highspeed DSL. Case closed.Article ID: W16882
File Created: 2007:07:03:14:26:42
Last Updated: 2007:07:03:14:26:42