I would think that suppressing this message wouldn't solve much. Your database would then be unresponsive and appear broken during the protracted delete.
I get the idea of using your exports to back up data, but why delete the data after exporting?
To save disk space,
Given that hard drives are now routinely hundreds, even thousands of Gigabytes in size, are you sure that what you are doing is worth the reduced space used on your hard drive?
"Given that hard drives are now routinely hundreds, even thousands of Gigabytes in size, are you sure that what you are doing is worth the reduced space used on your hard drive?"
As always thanks for your quick helpful response....
I apologize if I was not clear. The primary function of the implementation is not so much to save disk space, but to save my b*tt at update time.
During development when things are going fast and furious I have accidentally updated a runtime without first saving the tables - ouch! Fortunately, I use cloud back up and was able to restore old FM runtimes, most of the time, but this is painful and does not work 100% of the time. By having the tables written into a text format I am able to peruse the data of beta testers (raw or via Excel) to verify all is well with the option of starting or not starting an instance of FM pro or a FM runtime. Updates are trivial. I supply a clean FM runtime, the tester runs it and it works everytime by restoring from the saved csv data with no need to do a dump-restore.
In my case, this retrieve-save route is not too painful because clients will not likely have more than a few thousand records - ever (but you never know. :-), but each record can be large because it contains an image which can be of any size the user wishes to supply.
If you will allow me to dream on...it would be really neat to have FM runtimes have an option to autosave tables that have been touched or mark them for autosave when the program exits....dream off. :-)
Does FM have way I can use to detect if a table has been modified during a FM session? Only saving modified tables would help a lot. Most sessions either involve minor mods or data views in which little to no saves are required which would allow for conditional saves. I can implement this myself with flags if necessary.
Which explains why your are exporting the data but not why it then deletes the data.
Good question. I guess I can keep 2x the bloat, once in the csv files and another in the FM runtime (save, with no table deletes).
Your point well taken. Worrying about hundreds of MBs (likely less than 1G) is probably not worth the trouble.
I forgot, one related Q before we close (I asked this one earlier): is there a way to determine if a table was modified during a FM runtime session long after the mod occurred, i.e., just prior to program exit?
If so, it would save time if I could write only the modified tables back as csv files when the runtime is exited.
If this feature is not available I think it would be trivial to keep an internal global record with mapping to each table in which a modification flag could be set when mods occur.
I don't see why you would delete the data in the first place from a users point of view. Don't they need that data in the file to continue using the solution?
Tables cannot be modified by run time users. Data in the tables can be modified and you can set up auto-enter fields that auto-enter data whenever a record is modified such as a date, time or timestamp. With scripting, you can even log changes on a field by field basis within the records of your tables, though that makes for a lot of scripting.
Final thought: I wonder if a runtime can be scripted to save a clone (empty copy) of the runtime file. That should work and there might be ways to even swap out the original file for the clone automatically.