Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
how to make automatic backup in databases
- Thread starter zhed0708
- Start date
Mike Lewis
Programmer
SET AUTOSAVE has got nothing to do with making backups.
In most sites, there is a routine procedure for making backups of all files - not just VFP databases - usually using a separate backup utility of some kind. It's not usually the responsibility of the application.
If you defintely want to do it from within your application, you can do it quite simply by copying the files (but only if they are not open at the time).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
In most sites, there is a routine procedure for making backups of all files - not just VFP databases - usually using a separate backup utility of some kind. It's not usually the responsibility of the application.
If you defintely want to do it from within your application, you can do it quite simply by copying the files (but only if they are not open at the time).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
newtofoxpro
Programmer
Try this.. Condition is table should be open shared
cCmdLine="command.com /c copy customer.dbf customer.bak >65898934.tmp"
DECLARE INTEGER WinExec IN kernel32 STRING cCmdLine, INTEGER nCmdShow
=WinExec(cCmdLine,0)
RETURN
cCmdLine="command.com /c copy customer.dbf customer.bak >65898934.tmp"
DECLARE INTEGER WinExec IN kernel32 STRING cCmdLine, INTEGER nCmdShow
=WinExec(cCmdLine,0)
RETURN
Olaf Doschke
Programmer
there is COPY FILE in foxpro, besides I'd rather use some other machanism, eg a decent backup software simply backing up the directory of the database.
Bye, Olaf.
Bye, Olaf.
newtofoxpro
Programmer
@Olaf : 1) When COPY FILE fires table should not be open. It is difficult in multiuser environment. 2) When coping large table, myapplication will stuck-up till COPY FILE finish.
My Code is faster, works in multiuser environment & myapplication does not stop even large tables backups.
My Code is faster, works in multiuser environment & myapplication does not stop even large tables backups.
- Thread starter
- #6
newtofoxpro
Programmer
I usually put at before quitting myapplication. So when-ever I quit, myapplication makes backup and quit.
newtofoxpro
Programmer
Note : Don't Turn-Off-Computer when quitting myapplicaton. You Bakcup proccess is working in backgroud. So wait for 2-3 min. Approx.
Mike Lewis
Programmer
I really don't think this is a good approach.
Newtofoxpro, there's no point in calling the DOS COPY command, as you are proposing, rather than using the native VFP COPY FILE command. They both do the same thing under the skin.
I also question the concept of blindly copying files whenever the application closes. What if another user is in the middle of an update at that point? What if the user who is doing the copying gets fed up with waiting and switches off the computer?
It's much better to rely on a dedicated backup utility. Backups should be administered centrally, and not left to the whim of the application programmer. A proper utility will handle all the exceptional cases and other issues that might arise; it will keep track of the backups; and it will provide a safe way of restoring them when the time comes.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Newtofoxpro, there's no point in calling the DOS COPY command, as you are proposing, rather than using the native VFP COPY FILE command. They both do the same thing under the skin.
I also question the concept of blindly copying files whenever the application closes. What if another user is in the middle of an update at that point? What if the user who is doing the copying gets fed up with waiting and switches off the computer?
It's much better to rely on a dedicated backup utility. Backups should be administered centrally, and not left to the whim of the application programmer. A proper utility will handle all the exceptional cases and other issues that might arise; it will keep track of the backups; and it will provide a safe way of restoring them when the time comes.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #10
Olaf Doschke
Programmer
I said, I'd rather use some decent backup software, that means I don't opt for copy file, but I was just pointing out vfp has that command. command.com also can't copy files while other users have it opened. Backups should be done by backup software, even for such simple backups as vfp as it's simply files. Multiuser is problematic even though backup only needs read access. Did you ever had a restore? Any issues? how large is your largest table?
I've had a database with the largest table being in the GB range. It took half an hour to copy alone. As the copy did reach the end of that dbf there most certainly was already new data that was also saved, but with missing parent data from the parent tables, if they were copied previously.
Backup is something a server does over night, and then has exclusive access.
I also think zhed is more interested in more than just nightly recovery points of the database, but a transaction log which could be used to restore data up to the last failing transaction due to power failure, eg. For that aspect alone, zhed, better use Uninterruptable Power Supply hardware. I know a shop using that even in stable power supply regiosn like here in germany, and we're using that for servers.
Besides that, there is no transaction logging in vfp, you have to roll your own or better use an SQL Server backend.
Bye, Olaf.
I've had a database with the largest table being in the GB range. It took half an hour to copy alone. As the copy did reach the end of that dbf there most certainly was already new data that was also saved, but with missing parent data from the parent tables, if they were copied previously.
Backup is something a server does over night, and then has exclusive access.
I also think zhed is more interested in more than just nightly recovery points of the database, but a transaction log which could be used to restore data up to the last failing transaction due to power failure, eg. For that aspect alone, zhed, better use Uninterruptable Power Supply hardware. I know a shop using that even in stable power supply regiosn like here in germany, and we're using that for servers.
Besides that, there is no transaction logging in vfp, you have to roll your own or better use an SQL Server backend.
Bye, Olaf.
newtofoxpro
Programmer
@Zhed : "how to make automatic backup of databases"
I have deveoped good system which is running to my users from last 10 years approx. As you asked automatic backup, it does not mean that you are not providing manual backup for users.
If I advise to put my code while quitting, because it is my practice.
In fact, in my software I have developed backup system which run by PUSH_BUTTON which requires DATABASE CLOSED. This backup system manage by users. User can backup data to any drive including external HDD.
Apart from this, I have developed automatic backup system (as you asked) which run automatically. It happened several times my user ring me and said "For same reason I have lost my data & I have last week backup. Please do something" And I have restored data from auto-backup system with only one day data loss.
But you should not ignore Olaf & Mike's advices.
I have deveoped good system which is running to my users from last 10 years approx. As you asked automatic backup, it does not mean that you are not providing manual backup for users.
If I advise to put my code while quitting, because it is my practice.
In fact, in my software I have developed backup system which run by PUSH_BUTTON which requires DATABASE CLOSED. This backup system manage by users. User can backup data to any drive including external HDD.
Apart from this, I have developed automatic backup system (as you asked) which run automatically. It happened several times my user ring me and said "For same reason I have lost my data & I have last week backup. Please do something" And I have restored data from auto-backup system with only one day data loss.
But you should not ignore Olaf & Mike's advices.
Olaf Doschke
Programmer
newtofoxpro,
While I don't know the exact specifications, you backup starting with closing the databases sounds like a candidate for what I called "decent backup software", so you're not out, if it comes down to accepting that advice.
If you're picky, closing the database from the current user doesn't close it in total, other users still use files shared. As VFP is no server there is no central server element pushing out users, you can of course do so on the network level, cutting a server from the network no files is open by any network client of course.
If it comes to live backup I get back to my half told story about backing up a large database:
There was no error for any user or me while copying the files simply via xcopy, there is no hardware defect of files, but still due to the duration of the copy the header having the reccount of the table stored was half an hour older than the end of the file, to which records were added during copy: Again, without any error. The result copy was fully intact including eof, no area of the file was mangled or such, but the file size didn't match the header reccount.
In short: You don't do a snapshot backup, neither with vfps copy file, nor with comand.com copy or xcopy or whatever copy utility.
I know one snapshot mechanism that really also handles this downside of file copies from Acronis. I'm not their advocate, but have a read on this technology here in the last paragraph:
In short they hook into the file system on a really low level, and intercept every file operation on the valume to backup while backing it up. Therefore all programs don't get interrupted and can change files and read them as if they are really changed, while those changes really go into a seperate buffer. This way it can take as long as it takes, you still copy a snapshot of the files made by redirecting all changes into the buffer and then applying them after the backup.
To mimic this in your app you'd need some complex logic and I'd simply bye a backup software supporting this or a similar snapshot technique in regard to decent backups.
This still does not include any transaction log, it's just assuring the integrity of the data backed up by freezing files to that moment in a tricky but elegant way.
The only thing bad about it is, it takes a sec or two to get into that freeze mode, as described. during that time write operations fail and if you eg set VFPs RETRY too low that may cause a failure during that time. Otherwise it's a fine backup mechanism. This is what I really call decent. And that's that expert knowledge you only get from a professional backup software vendor.
I've googled for the filter technology mentioned in the acronis "advert" - "...the filter driver...". You can write such a filter, too, not with VFP though, and you need an SDK, which doesn't come for free. Here's a starting point on that:
But I recommend you buy a backup product, really. It would take some time learning this to write your own, if you're as picky as I am on backups. In the end it doesn't help much, if you revert from a backup that as header errors or missing parent or child records, even though there were no errors during backup.
Bye, Olaf.
While I don't know the exact specifications, you backup starting with closing the databases sounds like a candidate for what I called "decent backup software", so you're not out, if it comes down to accepting that advice.
If you're picky, closing the database from the current user doesn't close it in total, other users still use files shared. As VFP is no server there is no central server element pushing out users, you can of course do so on the network level, cutting a server from the network no files is open by any network client of course.
If it comes to live backup I get back to my half told story about backing up a large database:
There was no error for any user or me while copying the files simply via xcopy, there is no hardware defect of files, but still due to the duration of the copy the header having the reccount of the table stored was half an hour older than the end of the file, to which records were added during copy: Again, without any error. The result copy was fully intact including eof, no area of the file was mangled or such, but the file size didn't match the header reccount.
In short: You don't do a snapshot backup, neither with vfps copy file, nor with comand.com copy or xcopy or whatever copy utility.
I know one snapshot mechanism that really also handles this downside of file copies from Acronis. I'm not their advocate, but have a read on this technology here in the last paragraph:
In short they hook into the file system on a really low level, and intercept every file operation on the valume to backup while backing it up. Therefore all programs don't get interrupted and can change files and read them as if they are really changed, while those changes really go into a seperate buffer. This way it can take as long as it takes, you still copy a snapshot of the files made by redirecting all changes into the buffer and then applying them after the backup.
To mimic this in your app you'd need some complex logic and I'd simply bye a backup software supporting this or a similar snapshot technique in regard to decent backups.
This still does not include any transaction log, it's just assuring the integrity of the data backed up by freezing files to that moment in a tricky but elegant way.
The only thing bad about it is, it takes a sec or two to get into that freeze mode, as described. during that time write operations fail and if you eg set VFPs RETRY too low that may cause a failure during that time. Otherwise it's a fine backup mechanism. This is what I really call decent. And that's that expert knowledge you only get from a professional backup software vendor.
I've googled for the filter technology mentioned in the acronis "advert" - "...the filter driver...". You can write such a filter, too, not with VFP though, and you need an SDK, which doesn't come for free. Here's a starting point on that:
But I recommend you buy a backup product, really. It would take some time learning this to write your own, if you're as picky as I am on backups. In the end it doesn't help much, if you revert from a backup that as header errors or missing parent or child records, even though there were no errors during backup.
Bye, Olaf.
Mike Lewis
Programmer
Newtofoxpro,
You've made some interesting points.
But I'm not sure about your practice of automatically running a backup when the application quits. Of course, if it's been running successfully in your application for ten years, I can't argue with that.
In most cases, though, I don't think this is a good idea. What if a user launches the application simply to check a couple of records or to print a quick report - something they might do several times a day? It's seems onerous to expect them to wait for a full backup to be taken every time they do that.
Plus, there's still the multi-user issue to consider. If you've got ten users, and if each user triggers a backup every time they come out of your application, that's going to mean at least ten backups per day.
If you're taking that many backups, you will also need a way to manage them - if only to know which is the most recent. And having even the most up-to-date backups won't help if you don't have a good system for restoring them.
I still feel the best way to go is to have a dedicated backup tool, and to use it as part of a properly thought-out backup strategy.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
You've made some interesting points.
But I'm not sure about your practice of automatically running a backup when the application quits. Of course, if it's been running successfully in your application for ten years, I can't argue with that.
In most cases, though, I don't think this is a good idea. What if a user launches the application simply to check a couple of records or to print a quick report - something they might do several times a day? It's seems onerous to expect them to wait for a full backup to be taken every time they do that.
Plus, there's still the multi-user issue to consider. If you've got ten users, and if each user triggers a backup every time they come out of your application, that's going to mean at least ten backups per day.
If you're taking that many backups, you will also need a way to manage them - if only to know which is the most recent. And having even the most up-to-date backups won't help if you don't have a good system for restoring them.
I still feel the best way to go is to have a dedicated backup tool, and to use it as part of a properly thought-out backup strategy.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Status
Similar threads
- Locked
- Question
