Disaster(s) averted

"Not another update!" I can hear the cries now.
The main update for the year (version 4.4.2) was put on the Wessex website for download in March. This made the way the program works out the price much more flexible. Also, the way the program reads the xml User file was rewritten (you didn't really need to know that).

This upgrade (version 4.4.3) will hopefully prevent an overwritten database being completely irretrievable.
Up to now, if you imported a database (or User) file it was simply copied over the previous one. This didn't have to be a problem, because before you did anything as drastic as that you backed up all your data - you did, didn't you?

Of course that ignores the human factor - we're in a hurry, we didn't think things through, all sorts of reasons.
The solution must be easy, surely if a new database is being imported, simply copy the old one to somewhere on the computer?
Well, yes that could work, but it would also leave us with some potential problems. If it was copied to "My Documents" it could be quite easy to loose or delete. Copied to somewhere more obscure would mean that it was difficult to find.
The other potential problem is that copying the same file to the same place would mean overwriting the previous file. Potentially good data could be overwritten with bad data.

The solution - use the "Recycle Bin". Every PC has one, it's easy to access and will also take multiple copies of a file with the same title.
However, we could then be faced with a bin filled with files of the same name, not insurmountable (right-click and choose "Properties" to find out size, last modified, etc.) but a bit of a faff to sort out. Also, if the file was "restored" it would immediately overwrite the current database, even if the program was not running!

With a bit of nifty footwork we can get around all of these problems.
When you click "File" > "Import Database" the program checks the new database is compatible, then it warns you to check the dates of the old file and the new one to be imported.
When you tell it to continue it used to simply overwrite the old database.
Now, the old database file is copied to the "Desktop" with the date and time appended to its title. Straightaway it is then moved to the "Recycle Bin". So, if the file is restored, it is restored to the "Desktop" and can be dealt with from there. Clever eh?

If you peer at the above image of my Recycle Bin you will see that the database file is now labelled "V3_01052017_120726". To decipher that - "V3" is the database file, "01052017" is the date (01/05/2017) and "120726" is the time (12:07:26).
Then, it was easy to use virtually the same code to do the same thing with the "User" file (this contains the user's labels and values, which together with the database file made the program specific to a particular framer).
So, now the user will have to work a lot harder to lose their data!

NB. The above only works with the program's own internal database, so if you are using a networked database, you will need to make your own arrangements to copy and backup file.