Need to run 24/7, or you are tired of chasing down users that leave the application running.

Here is a company that offers a product to "Backup Open Files".

Open File Manager http://www.stbernard.com/whiteprpofm.html
or http://www.stbernard.com/products/ofm/products_ofm.asp

How it Works

Open File Manager monitors the file system for read requests coming from a backup program. It then begins maintaining a dynamically allocated Pre-Image Cache for all open files on the system. Only changed data is stored in the Pre-Image Cache, not entire files! When the backup application reaches a part of a file that has been changed, Open File Manager substitutes the original (pre-write) data from the Pre-Image Cache to fulfill the backup request. The file on the tape will then look exactly like it did when the backup application started. Meanwhile, users of the data have normal access to read and write to their files.

Scott Finegan

---

I am leery that this will work for dbfs. I think we can all agree that tables can get corrupted when a work station is shut off in the middle of a table update. What is the difference between the corrupted table, and the table that is backed up mid update? -- CFK Follow the link and read their slime. I can imagine poor programing practices could result in missing data, however the monitor agent freezes the image when there are no locks, or pending reads or writes. You can always try the DEMO.

---

Or create a little datamirror program that periodically does a COPY TO ... WITH CDX of all the data to another directory, ideally on a separate server, which is in the tape backup loop. For bonus points: rig this backup area to serve as a Warm Standby Server.-- Steven Black
And for more bonus points, replace the COPY TO.. with HTTPSPost() and shuttle your backup across the country to a Warm Stand By Server. Handy for those rolling blackout days. < s> -- lc

---

Even better, simply use COPY *.* to c:\BACKUP or some archiever.
This copys open dbf files well. Andrus Moor
This doesn't always work, and you won't know until you try to use the data. Scott
Actually it seems to work except for files used exclusive.
No, this does not work.

---

The COPY *.* dos command does create a backup of your files, but does not prevent corruption of the files when data is written to the files during a backup operation.

You might consider the following code

IF !DIRECTORY("dataexport")
	MD dataexport
ENDIF

=ADIR(aFiles,"data\*.*")

DECLARE INTEGER CopyFile IN KERNEL32.DLL ;
   STRING @SourceFileName, ;
   STRING @DestFileName, ;
   INTEGER bFailIfExists

nSucces=0
=ADIR(aDbfs,"data\*.dbf")
FOR nT = 1 TO ALEN(aDbfs,1)
	SELECT 0
	USE ("data\"+aDbfs[nT,1]) AGAIN ALIAS ("__Table"+ALLTRIM(STR(nT)))
	nSucces=IIF(FLOCK(),1,0)
	IF nSucces=0
		EXIT
	ENDIF
ENDFOR

IF nSucces # 0
	FOR nT = 1 TO ALEN(aFiles,1)
		nSucces=CopyFile(SYS(5)+SYS(2003)+"\data\"+aFiles[nT,1],SYS(5)+SYS(2003)+"\dataexport\"+aFiles[nT,1],0)
		IF nSucces = 0
			wait window aFiles[nT,1]
			exit
		ENDIF
	ENDFOR
ENDIF

IF nSucces = 0
	MESSAGEBOX("One or more files could not be copied",0,_VFP.Caption)
ELSE
	MESSAGEBOX("The export is copleted.",0,_VFP.Caption)
ENDIF
CLOSE DATA ALL - 

Walter Meester

---

No doubt I'm just missing something, but why isn't the following good enough for most situations?

*** At design-time ***
CREATE TABLE MyTable (......)

INDEX ON .... TAG ....

COPY FILE ..\LocationA\MyTable.dbf TO ..\LocationB\MyTable.dbf
COPY FILE ..\LocationA\MyTable.cdx TO ..\LocationB\MyTable.cdx
COPY FILE ..\LocationA\MyTable.fpt TO ..\LocationB\MyTable.fpt

*** At runtime ***
USE ..\LocationB\MyTable.dbf ALIAS BackupTable

ZAP

* This sequence is important. I could not get a SELECT ....
* INTO ..\LocationB\MyTable.dbf to work without mysteriously
* wiping out the backup .cdx file. However, SELECTing into
* a cursor and then APPENDing FROM it to the backup table
* works--and, I believe, keeps everyting in synch.
SELECT * FROM ..\LocationA\MyTable.dbf INTO CURSOR MyBackup

SELECT BackupTable

APPEND FROM DBF("MyBackup")

-- Ken Dibble

Caution: COPY FILE will blow up if the filespec is longer than 128 characters. -- Jim Wiggins

Ken, your solution is great for a backup within the application, but I think this is more to do with external applications backing up Visual FoxPro data on an automatic or continuous basis, where one or more users may have data files open.

In my opinion when discussing VFP data you will never get backups you can rely on 100% unless there are no users in the application. With transactions and caching and the lack of a mechanism to make clients resolve and flush all this to disk, you can't be sure of the overall integrity of the database even if you can successfully back up open files. -- Alan Bourke

---

Category Third Party Products