Hi Rick,

I'm looking at modernizing (if one can use that word in the context of a VFP application...) to use sftp instead of plain ftp. I've been using the OnFtpBufferUpdate as shown in your example in my current implementation hook, and at some point I discovered that setting nftpworkbuffersize to larger values gives me faster upload speeds, no doubt due to fewer calls to the OnFtpBufferUpdate hook. However, I was poking around somewhere whilst researching this and I swear I found something where you indicated that a specific maximum value (24576?) should be used or files can be corrupted in the process. Then I found a thread here in the board from 2017 that had another number (50000) but also was tied to a specific version of the DLL that supports sftp connections. Can you clarify what that maximum safe value is?

TIA

Not sure why there would be a physical limit to the buffer size. generally making the buffer too large doesn't end up increasing performance that much. 65k is a good starting point for large files, 128k for very large files. You can experiment to see what works best.

BufferSize effects the number of network connects that have to happen. If the buffer is larger more data is sent in a single chunk. This makes things faster. Too many updates add a lot of overhead too, for sure as interrupting raw data code with UI code is comparatively slow.

+++ Rick ---

The in-application FTP is sending JPGs so the average is probably in the several MB range. I had been using 65k which seems a decent value but got nervous when I ran across that reference which said any value over a certain number can result in file corruption.

Only reason I can think of is that this was something related to the base library. At the time though that library was in preview - I expect that to be fixed. But perhaps make sure if you use a bigger buffer.

But as said I think 65k is a pretty large buffer in general for network operations. Small buffers are 4k/8k. So I don't think you need to go any bigger. The network is only so fast.

+++ Rick ---