>
>Nothing that we could pinpoint, but generally there's opinion here that SpeedSend is not 100% reliable, and we actually don't avoid both of its aspects: when it updates an existing file, or when it just uses compression to speed it up. We didn't switch compression off, we just take care we don't have a file with the same name on target directory.
>
>Generally, zip files are a faster way to go, because you may get compression of up to 20:1 (on dbf files with many blank fields), which normally is about 1:3 to 1:4 for average files (peek at your typical zips to get your own estimate), and on-the-fly compression rarely goes above 2:1. Zip still needs to be unzipped on the target, and if the target machine is slow (so unzipping lasts) or the connection is bad (so you waste time waiting for WinZip to show buttons, dialogs etc), you may not be gaining that much.
>
>I think (nothing conclusive here) that anything being sent must have CRC, no matter what transport layer is used; it's simply standard nowadays. Without calculating the CRCs of each block on both source and destination file and comparing them, how would pcAW know which blocks need updates in SpeedSend in the first place?

Dragan,
this is the stuff I wanted to know. Many thanks. Sounds like we will stick with PKZip. Like you, I really like having that CRC check. We don't use WinZip. We use the old DOS PKZip. (We actually purchased it about 10 years ago.) This way we don't have to install yet another windows program. Our customers are all small auto body repair shops with little or no tech support so the less the better. You just have to be sure you don't have any file names longer than 8.3. We install the public domain copy when we install our system so it's aways there.