> Thanks for the input. Yes, I always copy the existing exe file, and anything else I am changing, to a \back sub dir before the change. We also upload the new file to a \new sub dir so the users don't have to get out while we do the time consuming upload. We then get everyone out for 30 seconds and copy the new files from \new to the app dir after copying the existing files from the app dir to \back. Not sure what you mean when you talk about disable SpeedSend. Have you had problems with it or do you mean only when someone has the file open? I am somewhat hesitant to use SpeedSend in place of a Zip file because PCZip has the CRC error checking. I would love to hear back from you about how SpeedSend has worked. Do you feel safe with it?

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?