>Hi charles,
>
>>Forgive me for being dense, but I still don't understand how you get long field names with the COPY TO command (since one is copying to free tables, no?). I have never been successful doing this. Am I missing something?
>
>The trick is that I don't use the COPY TO command, but the CopyFile API. The CopyFile API, like the DOS COPY command, creates an exact duplicate of the database files (or any other files for that matter).
>
>The problem with this approach is that when some user is modifying a table that is beeing copied, you may end up with either a corrupte table or a inconsistent database (loss of RI integrity). Therefore it might be handy to FLOCK the files at forehand (before using the CopyFile API), for example this might work for you:

CopyFile() and the other WinAPI copy operations ignores VFP's locking assertions short of USE EXCLUSIVE; the mechanism suggested requires that the backup be performed by the station issuing the locks, and always inserts travel to the local station performing the backup, with the net result that you may have data traversing the LAN needlessly twice when the source and target folders are on the same server, but the backup is performed from another station - the data is read from the source, passed to the station issing the copy, and sent to the target even if the source and destination are on the same box! Rather inefficient at a minimum, and no more reliable. You may as well OPEN DATABASE whatever EXCLUSIVE to prevent any other systems from using any database-controlled tables, and assuming that the mechanism to regenerate the DBC exists, which really does need to be supported in the event that we require restoring part of the data from backup, or where the DBC itself is damaged but the data itself is OK.

Without recursive relation cycles, it should be possible to establish an order of copying the tables one by one into an isomorphic empty database so that we can satisfy the RI rules of the database; the solution is expressable as a route for filling the data of each table that traverses each table of the database exactly once. Construct a graph whose nodes represent tables and vertices represent inclusive (some element of the table must be a member of an enumerable domain of values) relations. The vertices may be treated as vectors, since there is a single direction of membership, so in fact, the construct is a digraph. If we assume the direction of membership issues from a dependent node to the node establishing the realm of the domain, then, if there are no closed cycles in the digraph, it is provable that there exists at least one route of traversal of the nodes of the digraph such that each node is traversed (populated) after traversing all of it's destinations. If cycles exist in the digraph, it's possible to alter the topology of the digraph by either removing a relation to open the cycle; typically, this dependency involves a self-reference.

Given this, you could just as easily create a target DBC in the backup directory, and then APPEND FROM each original data file into the equivalent target table, without the issue of CopyFile() not respecting the state of DBFs. Or, you could do the whole thing in one call, with a Windows animation to show progress during the copy operation using SHFileOperation(), again assuming that you've created a DBC in the target directory:

DECLARE INTEGER SHFileOperation IN SHELL32.DLL STRING @ LPSHFILEOPSTRUCT
DECLARE INTEGER GetForegroundWindow IN WIN32API
DECLARE INTEGER GetLastError IN WIN32API
SET PROCEDURE TO CLSHEAP ADDITIVE
oHeap = CREATEOBJ('Heap')
#DEFINE FO_COPY 2
#DEFINE FOF_NOCONFIRMATION 0x10    &&  Don't prompt the user.
#DEFINE FOF_NOCONFIRMMKDIR 0x200   &&  don't confirm making any needed dirs
cSourceString = 'C:\MyApp\Data\*.DBF' + CHR(0) + ;
                'C:\MyApp\Data\*.FPT' + CHR(0) + ;
                'C:\MyApp\Data\*.?DX' + CHR(0) + CHR(0)
cDestString = 'D:\MyBackupDir\' + CHR(0) + CHR(0)
cProgressTitle = CHR(0) + CHR(0)
nStringBase = oHeap.AllocBlob(cSourceString+cDestString+cProgressTitle)
cFileOpStruct = NumToDWORD(GetForegroundWindow()) + ;
                NumToDWORD(FO_COPY) + ;
                NumToDWORD(nStringBase) + ;
                NumToDWORD(nStringBase + LEN(cSourceString)) + ;
                NumToDWORD(FOF_NOCONFIRMATION + FOF_NOCONFIRMMKDIR) + ;
                NumToDWORD(0) + ;
                NumToDWORD(0) + ;
                NumToDWORD(nStringBase + LEN(cSourceString)+LEN(cDestString))
nResult = SHFileOperation(@cFileOpStruct) = 0
IF nResult = 0
   *  It worked
   *  Check for Aborts
   IF DWORDToNum(SUBST(cFileOpStruct,21,4)) = 0
      *  Something was aborted
   ENDIF
ELSE
   *  Op failed - report result
   =MESSAGEBOX('File Operation failed - ' + TRANSFORM(nResult,'@0'))
ENDIF
oHeap = ''



>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)
>		THISFORM.Text1.Value=aFiles[nT,1]
>		IF nSucces = 0
>			wait window aFiles[nT,1]
>			exit
>		ENDIF
>	ENDFOR
>ENDIF
>
>IF nSucces = 0
>	MESSAGEBOX("Een of meerdere bestanden konden niet gekopieerd worden",0,_VFP.Caption)
>ELSE
>	MESSAGEBOX("De export is voltooid.",36,_VFP.Caption)
>ENDIF

>Good luck,
>
>Walter,