>>I'd like to be able to back up a VFP database ( i.e. DBC and associated tables ) even if one or more users are actively working with it. Preferably using VFP code, but I'm open to other techniques ( e.g. LLFF ) if necessary. I'd like to avoid 3rd-party applications if possible.
>>
>...
>>But, now it looks like a chicken-and-egg situation:
>>
>
>if the customer is aware of the chicken/egg and wants to stay that way,
>either go the vfp route but add the twist of adding your own homegrown version
>rowversion to each insert/update. This way you can aim for incremental updates and update more often.
>
>Or check out a disc imager where you can modify the path list (unless data sizes are small)
>- faster "byte mass" handling and compression option.
>
>And make clear in writing that both ways can result in a bad state,
>so the client will not have a change of opinion after the mess has exploded ;-)

I've been playing around with this a bit. I've been getting some funky results with Cetin's code:

- it would be nice to open and FLOCK() any table before copying it, so no-one else can modify it
- if I open and FLOCK() in the same process that does the LLFF, no errors but nothing gets copied (target files have zero bytes)
- if I open and FLOCK() in another VFP session, the LLFF copying in the first session seems to work fine
- Open and FLOCK() in a different datasession in the first VFP instance doesn't copy anything either

I'm trying to find a way to avoid having to open and manage another instance of VFP.