Back in the day I had a routine that attempted to use shared all dbfs and would copy to the backup folder. If a table was not able to be used that was noted in the log. When done all files were zipped into a single file. User could then copy that to floppy disk via a multi disk param or just leave them were they were. Next backup run would remove all of those files and repeat the process.
Today you can copy them to a usb key, secondary drive or the cloud.
On Tue, Aug 16, 2016 at 8:19 AM, Srikanth Bhandari < consultant@srikanthbhandari.ind.in> wrote:
I would suggest using some freeware to zip the VFP Dbc/Dbfs/Fpts/Idx/Cdx files before the zip file is copied to the iCloud.
You would require to schedule the Zip & Copy.
Most files aren't copied while being in use. Hence you might not have had the Transaction file getting copied since they would have been opened by the user(s) while the same was being copied.
On Monday 15 August 2016, Michael Glassman MHGlassman@pioneerdrama.com wrote:
Thanks for providing more details, Alan. Those are the same reasons I don't do continuous backups.
Mike
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com javascript:;] On Behalf Of Alan Bourke Sent: Monday, August 15, 2016 8:57 AM To: profoxtech@leafe.com javascript:; Subject: Re: iCloud
On Mon, 15 Aug 2016, at 03:24 PM, Michael Glassman wrote:
Just curious, Alan. What makes you say that?
Michael
Firstly I've seen a few (MozyPro in particular) hold a file handle on DBF/FPT/CDX files if they're in the backup upload queue, which can interfere with VFP.
Secondly VFP applications using DBF data are essentially a data set
spread
over many files, hundreds in our case. Unless you can do a 'point in
time'
backup when you know there is nobody in the system (like the traditional 3AM tape backup approach) then how do you know if restored data is
consistent?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]