Please pass this around, because a5 developers backups (using .dbf's) may be at risk of being USELESS!
My thoughts on the following matter is: "You can't fix stupidity, but you can (and should) take precautions!"
I recently uncovered what I consider to be a "bug." And in combination of the way the internal a5 backup tools behave, this essentially means (at present): It is IN FACT 100% possible, & plausible to create a backup (of a 100% functional and working .dbf database/program) that is missing table(s). ~ All a developer needs to do (to find himself/herself in this "unfortunate situation") is to do is drop the wrong table accidentally and not catch the mistake. (There is no warning that this has happened, until the backup is needed after a catastrophic failure.) ~ In which case, it's too late! The restored database will be missing these tables along with all the associated support files!
The consequences of this, when combined with the fact that the built-in a5 backup tools do NOT have a default setting (or any setting for that matter) to includes dropped objects leaves a developer with a potential disaster and thus IMHO creates unnecessary risk. ~ Incidentally, this is something I had recommended last year, for essentially this same reasons, before I uncovered this scenario even existed.)
Bottom line: "A developer should NOT & can NOT rely on the built-in backup routine in a5 (on a self contained & fully functional WORKING .dbf database) to re-generate a completely restore-able copy of the database."
CHECK YOUR DATABASES & BACKUPS TO MAKE SURE YOU DON'T HAVE ANY "DROPPED TABLES THAT SHOULDN'T HAVE BEEN DROPPED!"
My thoughts on the following matter is: "You can't fix stupidity, but you can (and should) take precautions!"
I recently uncovered what I consider to be a "bug." And in combination of the way the internal a5 backup tools behave, this essentially means (at present): It is IN FACT 100% possible, & plausible to create a backup (of a 100% functional and working .dbf database/program) that is missing table(s). ~ All a developer needs to do (to find himself/herself in this "unfortunate situation") is to do is drop the wrong table accidentally and not catch the mistake. (There is no warning that this has happened, until the backup is needed after a catastrophic failure.) ~ In which case, it's too late! The restored database will be missing these tables along with all the associated support files!
PROOF OF RISK/THREAT:
1.) Create 2 related tables.
2.) Generate a set from these tables. (Build a form from this set, use the wizard if you wish & save the form.)
3.) Next, drop a table (heck, drop both of them!)
3.) Run the form, double click on the set, view/edit the set. ~ Everything appears fine and the form still runs.
(Because although the tables were dropped, they are still physically located in the database directory.)
Note: Since there are no layout objects based solely on these individual tables, nothing but the tables disappear from the CP & the database is still 100% functional.
Now backup the entire (100% working database) and take a look at the zip!
You'll find the backup (zip) does not include these tables & their associated "support files." (because they were dropped "accidentally.")
~ Hence a restored database (although it ran 100% fine just prior to making the backup) cannot be restored from this zip.
~ In this instance, there are no warnings. (And in a "loaded" control panel, this is a very plausible possibility, give the lack of organizational tools.)
1.) Create 2 related tables.
2.) Generate a set from these tables. (Build a form from this set, use the wizard if you wish & save the form.)
3.) Next, drop a table (heck, drop both of them!)
3.) Run the form, double click on the set, view/edit the set. ~ Everything appears fine and the form still runs.
(Because although the tables were dropped, they are still physically located in the database directory.)
Note: Since there are no layout objects based solely on these individual tables, nothing but the tables disappear from the CP & the database is still 100% functional.
Now backup the entire (100% working database) and take a look at the zip!
You'll find the backup (zip) does not include these tables & their associated "support files." (because they were dropped "accidentally.")
~ Hence a restored database (although it ran 100% fine just prior to making the backup) cannot be restored from this zip.
~ In this instance, there are no warnings. (And in a "loaded" control panel, this is a very plausible possibility, give the lack of organizational tools.)
The consequences of this, when combined with the fact that the built-in a5 backup tools do NOT have a default setting (or any setting for that matter) to includes dropped objects leaves a developer with a potential disaster and thus IMHO creates unnecessary risk. ~ Incidentally, this is something I had recommended last year, for essentially this same reasons, before I uncovered this scenario even existed.)
I had also recently suggested, that (in absence of folder organizational control within the control panel) that "color coding" (assigning color attributes to individual objects via right click) be added to provide some sort of visual organization/cues. ~ It's easy to "loose things" (and make mistakes like dropping the wrong table) as the CP fills with a lot of objects present. (After duplicating objects, color coding may also eliminate the need to drop some of these objects in the first place.)
Bottom line: "A developer should NOT & can NOT rely on the built-in backup routine in a5 (on a self contained & fully functional WORKING .dbf database) to re-generate a completely restore-able copy of the database."
Unfortunately, Selwyn doesn't consider this a bug! (Nor does he consider it a problem, and thus there are apparently no intentions to address this.)
I had hoped (expected actually) that Alpha Software's business philosophy included taking "reasonable initiatives to protect user data" whenever possible.
I had hoped (expected actually) that Alpha Software's business philosophy included taking "reasonable initiatives to protect user data" whenever possible.
CHECK YOUR DATABASES & BACKUPS TO MAKE SURE YOU DON'T HAVE ANY "DROPPED TABLES THAT SHOULDN'T HAVE BEEN DROPPED!"
Comment