6 Replies Latest reply on Feb 7, 2013 2:31 PM by philmodjunk

    Can I suppress the "Delete" panel

    dzittin

      Title

      Can I suppress the "Delete" panel

      Post

           Background: To save disk space, I save (csv files) all records, then delete all records to reduce the runtime size so there is only one copy of the data. (Yes, I know this is cumbersome, but it has saved my tail more than once when it comes to updating runtimes.).

           So, the Q: somewhere in the FM machinery some logic kicks in when deletes take more than 'N' units of time causing a panel of the form:

           Title: Delete, busy bar, "Records remaining: [count]"

           Of course, this freaks out the naive user and I need to suppress this panel if possible. For grins I tried turning error messages off to see if this would work and as expected it does not.

           Can I suppress this message?

           Thanks IA.

        • 1. Re: Can I suppress the "Delete" panel
          philmodjunk

               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?

          • 2. Re: Can I suppress the "Delete" panel
            dzittin

                 "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.

                 Thanks.

                  

                  

                  

            • 3. Re: Can I suppress the "Delete" panel
              philmodjunk

                   Which explains why your are exporting the data but not why it then deletes the data.

              • 4. Re: Can I suppress the "Delete" panel
                dzittin

                     Hi PhilModJunk,

                     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.

                     Thanks!

                      

                      

                • 5. Re: Can I suppress the "Delete" panel
                  dzittin

                       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.

                       Thanks!

                        

                  • 6. Re: Can I suppress the "Delete" panel
                    philmodjunk

                         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.