Gerrit, that's fine, as your VFP backp tool is a) scheduled by the system task scheduler, that's what's a cronjob is, and b) is not the application.
In fact I have also managed an application were the original developer was doing the backup of a database when the last user left the application on a day. But that has caveats. If a user left the app open no backup was done.
So I still stand by the recommendation that the app that uses a database, even the only app using it, should not be made responsible for the backup task. It's not because of it being technically impossible, but having a flaw of logic means no backup is done. So the reponsibility of the backup is on the server system. Now it depends on whether it being a Linux or Windows server, what tool is available for cronjobs.
If you have MySQL on a Windows server, maybe even on premise then I think cron is still available through the MySQL server itself as it is an always running service and has an event scheduler option within it:
But you could use the Windows task scheduler. And the straightforward backup tool is indeed mysqldump. That could also be started from the task scheduler without needing a specific VFP exe for that, as a cmd/bat file. But surely you won't start the application.exe to use it's backup feature. You're overall not depending on VFP and using VFP here boild down to the conveniece of knowing VFP in and out. If your VFPmysqlbackup.exe only uses myqldump, that's just crying out loud you don't want to write batch files.
But let's go further and look into the options of MySQL backups. As far as I know MySQL's backup documentation it says that myssqldump is a best option aside from binary file backups at least from time to time - let me lookup where it says so.
Found it at
Logical Backups Using mysqldump
In addition to physical backups, it is recommended that you regularly create logical backups by dumping your tables using mysqldump. A binary file might be corrupted without you noticing it. Dumped tables are stored into text files that are human-readable, so spotting table corruption becomes easier. Also, because the format is simpler, the chance for serious data corruption is smaller.
And while that's written in the topic about InnoDB backup specifically, this is a good recommendation generally.
The documentation also says (
...Physical backup methods are faster than logical ones because they involve only file copying without conversion.
So you can also look from that perspective and not use mysqldump for every backup but use a combination of physical (binary) backups, also incremental backups and use mysqldump for logical backups. A plan could use a full physical backup every 8 hours, an incremental backup every hour except every 8th hour, and once a day a mysqldump. Don't underestimate how the database can grow and spike up the time necessary for a mysqldump.
After the quote I gave from
this paragraph continues:
mysqldump also has a --single-transaction option for making a consistent snapshot without locking out other clients.
So that makes it viable to use during application and database usage, too. But it's not an argument of using it for every backup, you could get to a day where this snapshot mysqldump then backs up is taking it long to keep up the snapshot in memory, and that reduces the memory available for caching and other MySQL optimizations. It's, therefore, better to only need this once each day, even with this option. Especially as you want to back up more than once a day. Higher frequency backups also ask for incremental backups only. In MSSQL Server you'd do that for log backups also to be able to truncate the log more often.
In a very large system, I'd also rather do replication and have the replicated database or even multiple replications as both safety copies and therefore backups and also for high availability and performance by load balancing queries to multiple instances. You can also easily do a backup of a replicated version without any influence on the main database server and performance. But that would all point to an Enterprise MySQL license and NDB cluster usage. I doubt you're anywhere near such a MySQL usage.
Chriss
