Hi Mandy,
if this suits you, fine. You could remove a lot of repetition, though, if you follow Mike Lewi's advice to use DTOC() or use DTOS(). If you absolutely insist on MMDDDYYYY format, then that's also possible with SET DATE TO DMY and SET SEPARATOR '', but the least you can do is store the current date in that format into a variable tcToday and use that in all furhter code. Then it's not only less cluttered, it only becomes readable again, once you do that:
Code:
Local tcToday
tcToday = ALLTRIM(STR((MONTH(DATE())))) + ALLTRIM(STR(DAY(DATE()))) + ALLTRIM(STR(YEAR(DATE())))
Besides that, you create the table twice with CREATE TABLE and COPY STRUCTURE. I should have already addressed that when you posted your backup code at 20 Jun 22 06:39. Steve told you to do COPY TO ('E:\'+ADDBS(DTOC(DATE()))+'smsrec') and that's done instead of your code, the only requirement for COPY TO is you have opened what you want to COPY TO the destination file. and that needs an MDIR first, but no CREATE TABLE nor COPY STRUCTURE. If you do that, you even create the table three times.
I'd even make this one step easier and make a backup by a COPY FILE command.
So this is all you need for backup:
Code:
Local tcToday
tcToday = DTOS(DATE())
If !Directory('C:\INFOWAVE 2021\dbf\'+ tcToday)
MKDIR ('C:\INFOWAVE 2021\dbf\'+tcToday)
Endif
USE sms EXCLUSIVE alias tsulat && just to ensure you have exclusive access and copy without modifications done while copying
COPY FILE (ForceExt(dbf('tsulat'),'*') To ('C:\INFOWAVE 2021\dbf\'+tcToday+'\sms.*)
Which copies dbf, fpt (if it exsits), and cdx (if it exists). Even better copy a whole folder with *.* instead of sms.* by using
Code:
COPY FILE (Justpath(dbf('tsulat'))+'\*.* ) To ('C:\INFOWAVE 2021\dbf\'+tcToday+'\*.*')
CAUTION: If you have subfolders you also need to backup, then backup methods outside of VFP are more appropriate, i.e. backups are a system built-in functionality, you can make use of the OS, here. Since your current backup only copies the sms.dbf, I assume that's not the case. But keep in mind a simple data directory with no subfolders is copied with only one COPY FILE command also in VFP, thanks to the *.* file name pattern you can apply to both source and destination. of COPY FILE.
Steve Meyerson said:
more bad things are likely to happen at bootup than at shutdown.
I disagree with that, by the way. A process that's at the end can have quite some things worn out, in the worst case unclosed file handles, dangling object references, pending garbage collection and many more things that you can guarantee not exist at start of a program.
There still are good reasons to do a backup as last action of your application instead of backup at start. Mainly simply, that all the time before the start there is no backup, you create a backup directly after work is finished. But it could be done completely separate outside of your application by a scheduled task that would copy a data directory to a backup folder. It pays to learn about scheduled tasks, not only for the aspect of a backup, any task you could do regularly is worth considering to be scheduled. You have many options to do this at start, time based, but also at the end, when a process stops running and many more scenarios of which some also are very handy for the backup task.
Besides, you could temporarily delete the file share so you can be sure there is no usage of files through LAN again. Because even if you checked you can get all files exclusive, next moment that can become invalid again. After backup is done, the share can be reestablished. The command to use is the shell command NET SHARE to both create and delete shares (with the /DELETE option), which you can use by RUN.
IIRC you talked about end of a shift is mid day, so we're not talking about end of work of all employees or, again IIRC teachers in this case. I could assume this software is about the main time of a school in the morning and so the software usage stops mid day, in the afternoon other software or other features are used.
You could also inverse the task and implement something that shuts down clients when you want to shut down the server. I understand that your motivation is to actually keep the server up while files are still used, which is a sign your application is still used. But that file usage might be just having a file open and not doing anything. That relates back to detecting the idle state. You have all, at least most ingredients for that.
The ideal case is to remove the share while you have all files in exclusive access to prove no shared usage. Then you guarantee no further starts and new file access could be made and then you can be confident deleting the share cuts no file access, the only file access is by you, locally. With no share, nothing can be done to the files while the backup is done. And then it also doesn't matter whether you shutdown after the backup or allow users back in after reestablishing the file share. You establish a kind of floodgate this way.
Chriss