>Hi all ,
>Have u guys experience the problem about backup/restore the database ?
>In case of my program will change to resell version ,I wanna let the user can config the path of the backup directory .
>Now I only use stupid "copy c:\project\*.d* e:" .
>And it's cannot config by user .
>And the filename may change to abcdef~1.abc .
>Beside of using API ,any idea ?

You can simply use name resolution to specify the target path:

lcTargetPath = GETDIR('E:','Specify the backup target directory')
COPY FILE C:\PROJECT\*.D* TO (lcTargetPath)

I'd tend to use either the Scripting.FileSystemObject from the WSH or SHFileOperation() API call rather than the command line COPY or internal COPY FILE command. For internal backup of directories within the app, I tend to use SHFileOperation(), since it will operate recursively on a directory structure, permits me to track partial success, identifying files skipped during the COPY operation, and will display the Windows file copy dialog/animation while it runs if the operation takes long enough; it can also prompt for file overwrites, creation of new directories and supports automatic renaming of files rather than overwriting files with the same name in the target directory. There's sample code in the Win API section for it. Scripting.FileSystemObject is a COM component used by the Windows Script Host offering file and folder level operations which can be used by VFP, which offers additional capabilities to VFP's native functions. VFP's internal COPY FILE allows more flexibility than your current external COPY command. Lots of people use a commercial ZIP product such as WinZip or the DynaZip ActiveX control to back up their files inside their app, letting them save a complete set of data in a single file, compressing the data at the same time.

IOW, plenty of methods of making backups of files are available to VFP; some are free, there are commercial products offering extra capabilities if needed. There are internal VFP commands, API calls and COM components usable inside VFP which offer programmatic interfaces for copying files. No need to run the COPY command.

I also have my clients use a commercial backup product such as Seagate Backup or CA ARCServe to permit them to back up to tape, run the backup unattended, manage and log the backup automatically outside the app itself, and to back up much more than just my data files. Automated, logged, unattended backup, especially that is written on removable media is extremely important; having more than one backup copy is extremely important, and having one that's external to the system, and can be stored separately from the system, is needed - a backup on the same machine is useless if the machine is stolen or there's a fire, and making a second copy of your files on the same disk drive is of no use if the disk drive dies or the file system is destroyed by a virus; a separate, offline backup handles this, and commercial automated backup software will ensure that the backup is made without the user having to watch it or start it, and it's likely that there's lots more to be backed up than just the data file for my app from one directory.

If nothing else, .FPTs and .CDXs must be backed up as well as the .D?? files, you need to ensure that the files are not open for writing by another user during the backup, and that the backed up data is consistent - nothing gets altered while the backup is done, so all the data reflects the same state of reference.

I think you need to reevaluate what gets backed up, as well as the command used for copying the files. I don't know why you don't consider the Windows APIs, since inside the other methods, the Windows API ends up being used to perform the actual work, but many other options exist anyway.