>I am testing here and found out that vfpcompression.fll
>can ZIP even tables in use
>
>I am right ?
>I thought I would get an error message while trying to zip or copy
>a table in use
>
>
>******************************************
>SET LIBRARY TO vfpcompression.fll ADDITIVE
>
> DO FORM wait_bkp NAME WAIT1
>
> ZipOpen("C:\dados_assist.zip")
>
>
> * ?ZipFolder("C:\1softwares\1_assist41X\assist41", .F.)
> ZipFolder(SYS(5) + curdir() + "dados\", .T.)
>
> *!* could zip other files and folders here before close
> ZipClose()
>SET LIBRARY TO
>
>THISFORM.Visible = .F.
>THISFORM.RELEASE
>*************************************

It depends on how the zipping app opens the file. Some would try to lock the file, to ensure integrity, i.e. to make sure the file's contents won't change during the zipping, and then additionally calculate the CRC once more and compare it with the saved CRC just to make sure everything's fine. This is how the original PkZip (by Phil Katz) works.

Now a zipper may just take the bytes off the disk as they are, without much checking, and basically give you a snapshot of whatever the state your file was in - dirty buffers on workstations be damned. This way you may get it to zip the tables under any possible circumstances, but there's a risk involved. The related files may not be so related in the zip - your table may not have the same records as its indexes and fpt files think it has; the dbf may have one set of records, the cdx may be a correct index of another set (different from the first by a couple of records or more), and the fpt may have a different number of memos, to the point where you may get a "memo file missing/invalid" or an index related error when you unzip and open such a table.

You may force a flush of all the records by opening the table Again, forcing a change (set any numeric field to one more, than one less, or change its sign twice), then close it. That should tell the OS to force all workstations to flush their buffers (although I'm not sure it always works, in all versions of Windowses), and that may mean that the file on disk is clean at the moment. But if it's a big table, it may take several seconds to zip the dbf, then several more for the .cdx, then more for .fpt - can you guarantee the table remained intact meanwhile? Can you guarantee that for each table?

I haven't tried VfpCompression, so I wouldn't know how that works - you need to test for yourself.