VFP - Backup strategy

Do you know a way to fire a backup routine from inside a VFP application ? I've done one but it's unsatisfactory because I could not configure drivers since I use "RUN" - accordingly to the code furnished

Besides that foxpro has a copy file comand, like Cyril shows, why RUN copy? The Shell.Application will support Zipping the way Cyril shows in Win XP and above. For Win2k and older you may stay with your

Why not let the user choose where to store the backup? Why do you need to autodetect the drive? Also, once you determined which drive, use macro substitution to not have copies of the code for each different drive letter eg

A second and more evil problem is, that lha has no chance to know what the current directory is within foxpro. So to compress the gecc table you need to specify the full path to the dbf and fpt. See DBF() on how to get the path of a dbf. Also Sys(5)+Sys(2003) or fullpath(curdir()) will give you the path of the current directory foxpro looks for a file, but lha does not.

Besides that foxpro has a copy file comand, like Cyril shows, why RUN copy? The Shell.Application will support Zipping the way Cyril shows in Win XP and above. For Win2k and older you may stay with your lha compression.

Further Explanation: The Shell.Application (The Windows Explorer in fact) does treat a new empty ZIP file as a folder, so you can copy files into it, which actually zips them, that's the trick. You can't do that way of zipping with COPY FILE, but you can also remain with lha or use Craig Boyds VFPCompression FLL, tushar points to. There are several ways to compress files, that's all.

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

I'm not sure but the Namespace() method of Shell.Application may fail before some SP. But as you got it going, the reason was the file not existing.

Yes, the empty zip must exist before copying to it. As I already said - please read and you'd already got the answer - the ZIP support of the OS (without any Zip programm installed!) handles ZIP files as folders of the file system, therefore an empty zip file is just an empty folder and you can copy to it with the CopeyHere() method of the Shell.Application object.

The StrToFile() line is creating the zip file header that make it a zip file with no content.

Regarding .bak, sorry, what are you talking about? Cyrils code does not create a .bak file.

Cyril has put the final destination as cDestination = "c:\geccvfp\20100904.bak" COPY FILE (cTempZip) TO (cDestination) then copies the zip file and renames it as .bak file at the same time, but nothing changes in the file, it remains a zip.

That's simply a possibility of the COPY FILE command of foxpro, you cannot only determine a folder as the destination but also determine how the copy of a file should be named. To me that's some kind of a quirk, as you can also do something like COPY FILE d:\sourcefolder\*.* to d:\destinationfolder\destinatipn.bak and then would not concatenate all files of the source folder into the destination.bak file, but the destination.bak file would simply be the last file copied, it would be overwritten several times for each file of the source folder. I rather only use COPY FILE with a destination folder, but it's working to name the destination file, if you are sure the source just is one file. And it has the advantage, that the temp.zip can always be named the same, while the destination file could be named according to the date the bakup is made.

You can also define cDEstination as a folder eg cDestination = "c:\geccvfp\" and the COPY FILE program would then simply copy the zip file into that folder as a normal file copy does.

This code that I have supplied exports datasets on my program to a zip file to be give to another user elsewhere in the world.

You may ask why it is written as such:

Thermometer is a custom made progress bar. Some data is big and it takes up to 1 minute to compress.
I use sleep because of Vista. Vista uses so many effects and info while copying and the sleep prevents the timeout. The codes works fine on XP without the sleep.
I copy to a temp folder since the zip utility in Windows has access to the temp folders and Vista and 7 don't fuss about it. At the end I copy the file in the name I wish to the destination.

(I need to try to guess the driver the user will put his pen drive to copy the .bak so I keep the diskspace part - usually the machines have more than one possibility and every machine "decides" the drive letter)

there is a way to find out which drive is a usb pen drive, take a look at the solutions sample on windows events called "Binding to Windows Message events". Within it you can choose "media events", which means media in the sense of data storage media and it shows how to detect usb drive attaching and detaching.

Also you can check the drivetype() of a drive letter, loop from d to z and see if the drivetype is a removable drive (4). Unfortunately that can also be a network drive.

But last not least, why not let the user simply choose what drive, if you list all driveletters of drivetype 4. Besides that a network drive may also be a good candidate for a backup, it's an external drive in the first place.

Bye, Olaf.

0

Featured Post

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline