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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Set automatic backup to program

Status
Not open for further replies.

TreizeRXH

MIS
Sep 17, 2015
6
US
Hi all,


We have a program written that opens up a few tables and sets relations to each other so that we can better organize and edit markets in our databases. How can you set the program so that it creates a backup of each database should you ever make a deletion and potentially need to go back and correct the mistake?
 
Welcome to the forum.

When you say you want to "set the program", I assume you mean you want to write some code to create the backup - as opposed to using an existing back-up utility.

If that's correct, it should be quite straightforward. A backup is, after all, simply a copy. You can create a copy with the COPY FILE command. So, suppose the file you want to copy is CUSTOMER.DBF, you would simply execute this command:

[tt]COPY FILE Customer.DBF c:\backup[/tt]

(assuming c:\backup is your backup folder).

You would need to do that for each file in turn. (But you can also use wildcards in the filenames, for example [tt]COPY FILE *.DBF ....[/tt]).

If the file is not in VFP's default directory or search path, be sure to include a path name with the filename.

When copying database tables (DBFs), you will also need to copy the relevant memo (FPT) and index (CDX) files. Be sure to keep these in sync, otherwise you might have problems if you ever need to restore a backup.

Finally, keep in mind that you cannot do the above while the file is open.

If I have misunderstood your question, perhaps you could clarify what you are trying to achieve.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Another way of doing this could be to backup only the records you change. As in, when you click on a command button such as 'Modify', copy the current record (and maybe associated child records) to a backup table.
I actually make copies of records as the 'Change' button is clicked, then again as the 'Save' button is clicked. That way I have an audit trail - a before and after snapshot:
Code:
SELECT aTable
SCATTER MEMVAR MEMO
INSERT INTO aBackupTable FROM MEMVAR 

SELECT bTable
SCATTER MEMVAR MEMO
INSERT INTO bBackupTable FROM MEMVAR 
...

SELECT aTable
do whatever


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Backups are always good. I have automatic backups in place to 4 different places going automatic every night.
Only one of them are from VFP though, and if you only are concerned about an occasional delete I hope you know that deleted records actually remains in the table as long as it not is packed?
 
Yes, you can undelete a record either by un"checking" or removing the black deletion mark in a browse of a table you view with SET DELETED OFF to also show deleted rows or you move to such a record you know exists and then RECALL it.

Bye, Olaf.
 
How can you set the program so that it creates a backup.....
Basically you cannot just SET an existing program to do something that it does not already have the capability to do.

Additionally FP/VFP applications do not have an inherent 'native' backup routine.
Fortunately a Backup routine is relatively easy to write.

Both Mike & Dave have given you some good advice above in that you will either have to write some modifications into the existing code or use some 'external' utility/program to write the backups.

should you ever make a deletion and potentially need to go back and correct the mistake
An 'external' backup utility will not likely be 'sensitive' to changes in the existing tables unless it were to run consistently in parallel to the other application and periodically checking for changes upon which it would take some action.

To best achieve the interactive functionality you describe, your best bet would be to make a modification to your existing application's code and add the needed backup functionality to it - assuming that you had the source code available to you.

Good Luck,
JRB-Bldr


 
Thanks guys, I appreciate all the input. I'm still having a little difficulty getting it to work. I'm pasting my code below to see if maybe anyone can make sense of everything (p.s. I've changed the names of the dbf files just for the sake of corporate). Bear with me please as I'm a little new to the FoxPro environment and still trying to wrap my head around everything.

CLOSE ALL
CLEAR
CLEAR MEMORY

IF !USED("mid data")
COPY FILE mid data.dbf C:\Users\hernru04\Desktop\Test_AH Open the set\Backups <----THIS is my attempt at the copy command Mike mentioned above
USE "C:\Users\Treize\Desktop\Test_AH Open the set\mid data.dbf" IN 0 EXCLUSIVE
ENDIF
IF !USED("open_end_defs")
USE "C:\Users\Treize\Desktop\Test_AH Open the set\open_end_defs.dbf" IN 0 ORDER Market EXCLUSIVE
ENDIF
IF !USED("open_end_data")
USE "C:\Users\Treize\Desktop\Test_AH Open the set\open_end_data.dbf" IN 0 ORDER Market EXCLUSIVE
ENDIF
IF !USED("codes")
USE "C:\Users\Treize\Desktop\Test_AH Open the set\codes.dbf" IN 0 ORDER Market EXCLUSIVE
ENDIF
IF !USED("range")
USE "C:\Users\Treize\Desktop\Test_AH Open the set\range.dbf" IN 0 ORDER Market EXCLUSIVE
ENDIF
SET RELATION TO Mid_data.temlpate INTO Open_end_defs ADDITIVE
SET RELATION TO Mid_data.temlpate INTO open_end_data ADDITIVE
SET RELATION TO Mid_data.temlpate INTO codes ADDITIVE
SET RELATION TO Mid_data.temlpate INTO range ADDITIVE
 
Backup while the file is open.

Please try

use customer.dbf
run /n7 cmd.exe /c copy customer.dbf customer.bak
 
OK so you are going to write a whole new separate VFP application to use for the Backups?
This will indeed work, but it will not be 'sensitive' to only running when Record Changes and/or Deletes have been made.
And, as shown, it will not backup only those Changed or Deleted records.

Since you are new to VFP, I'd recommend that you spend some time watching the Free VFP tutorial videos at: They will not specifically address Backups, but they will give you a general idea how to work with Data Tables, etc.

Also something to understand...

The command: IF !USED("mid data") will only check if the Data Table in USE within the same Program on that specific workstation.
But it will NOT test if another user has the same table in USE on a different workstation (no matter what FP/VFP program/application they are using).

You should also understand that some application usage requires that a Data Table be used EXCLUSIVELY and other uses will be as SHARED.
If someone has the Data Table in USE EXCLUSIVE, you will NOT be able to access it until they are done.
However is someone has the Data Table in USE SHARED (or just NOT EXCLUSIVE) then you can also access it concurrently fine.

One possibility would be to learn about and use the ON ERROR approach to determine if you were NOT able to get access to a table and then handle it as desired. Within your VFP Development environment you can enter: HELP ON ERROR Command and HELP Error Messages Listed Alphabetically to see the list of error messages you might want to trap for.
Also here are a few examples:
Lastly you do not NEED to USE the tables EXCLUSIVE (although you can do so) in order to back them up.
It would have the benefit of testing if someone else had the table in USE. If so, your own EXCLUSIVE access would be prevented.

Another couple of notes about the code you have posted.
Code:
IF !USED("open_end_defs")
USE "C:\Users\Treize\Desktop\Test_AH Open the set\open_end_defs.dbf" IN 0 ORDER Market EXCLUSIVE
ENDIF
I am not sure what you are trying to do with this.
You test one ALIAS (or table name) to see if it is in USE
And then you look like you are trying to USE a different table - although the code line shown will not work.

Another item is that you do not specifically show which table is SELECTED before you begin setting RELATIONS.
Yes, the last table Opened will be SELECTED, and if that is what you want, then OK, but personally I like to specifically use something like:
SELECT ParentTable
SET RELATION TO <whatever> INTO ChildTable ADDITIVE


Good Luck,
JRB-Bldr
 
Spaces in file names will be turned to underscores in alias names, so USED("mid data") will never ever be true, USED checks for used workarea/alias names, never for file names.

Bye, Olaf.
 
In addition to the other's comments, the COPY FILE command requires the keyword TO between the two filenames:

Code:
COPY FILE File1 TO File2

Tamar
 
I have been using the following for years. The reindex program deletes all index files and reindexs them. All file are copy to the new subdir such as 'sav50925' which is for 9/25/2015. I do this once a week for many years. I can go back to any time period and run it.

CLOSE tables
FLUSH force
Set Exclusive On
Do Reindex.prg
CLOSE tables
!del *.fxp
!del *.bak
Clea
Set Century On
tmpm=Alltrim(Str(Month(Date())))
tmpd=Alltrim(Str(Day(Date())))
tmpy=Alltrim(Str(Year(Date())))
tmpm=Iif(Len(tmpm)= 1,'0'+tmpm,tmpm)
tmpd=Iif(Len(tmpd)= 1,'0'+tmpd,tmpd)
mbak='sav'+Substr(tmpy,4,1)+tmpm+tmpd
!Md &mbak
!Copy *.* &mbak
 
>The reindex program deletes all index files and reindexs them
This gives me another iea, you can save thespace for indexes (unless there is an index on a nondeterminstic expression like DATETIME())

And let me pick up another earlier idea:
Dave Summers said:
backup only the records you change.

He did it with SCATTER/GATHER, if your dbf is part of a dbc you can use audit trail via stored procedures to copy any record into a history of changes, which would work for all code canging data.
If your dbfs are not part of a dbc it's not so easy if legacy code needs access to the dbfs. If your executables all run on newer runtimes you can simply CREATE DATABASE your.dbc and ADD TABLE all tables to it, to make use of stored procs.

Last not least of course this takes time, so its a trade off between the security of logging all changes and the speed of any data updates. The only case this will really be noticanle is with mass updates.
Takenote once provided FoxAudit, and TaxRI was another product for referential integrity triggers also offering audit trailing as additional feature. Indeed triggers used t check referential integrity can alo help you prevent any changes not valid in regard to recods referencing records of other tables via foreign keys and check, whether the exist. it can also cascade changes, typicaly cascading deletes. The typical setpu rather is defensive, though, eg only allowing deleting a record, if no other record references it.

Bye, Olaf.
 
tfs2001 wrote:
Code:
Set Century On
tmpm=Alltrim(Str(Month(Date())))
tmpd=Alltrim(Str(Day(Date())))
tmpy=Alltrim(Str(Year(Date())))
tmpm=Iif(Len(tmpm)= 1,'0'+tmpm,tmpm)
tmpd=Iif(Len(tmpd)= 1,'0'+tmpd,tmpd)
mbak='sav'+Substr(tmpy,4,1)+tmpm+tmpd

This can be shortened to:
mbak='sav'+SUBSTR(DTOS(DATE()),3)
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top