Here are some random thoughts.
I believe that the initial target of the improved sandbox was to satisfy CTOs in large corporations that Quick Base is serious software. Serious IT managers do not believe in maintaining airplane engines while the airplane is flying, with the mechanic hanging off the wing with a wrench. They feel that the maintenance should be done safely, tested and the deployed to live, just like most serious software.
Most if us who have been at this for a long time are used to the old way, which is
1. Be Careful.
2. Make critical changes off hours, so evenings and weekends.
2. If unsure, make a backup copy to either test a major change, like a Key field change or to have a backup copy available to manually recover by looking back on how it used to work before we broke it, or else if all else fails reach out to Quick Base support to to recover last data or to roll back to the previous day (with potential loss of data for the current day)
The advantage of making changes on the fly when you mostly know what you are doing is that the changes are quick and hence low cost.
But for example, I'm working with a client where I have written apps for 17 years and trying to train a protege to take over 1st level support. It could be safer for some changes to be made and tested in the Sandbox because he may not know all the ramifications of a change.
So, it's a balance of speed and expediency with higher risk vs slower but safer and with more cost, in terms of direct cost for the Subscription and also more testing investment, that has to be assessed for each App.
In larger IT shops, the IT manager would probably just "mandate" the sandbox for any critical apps. For the rest of us, it's a decision.
------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.commarkshnier2@gmail.com
------------------------------
