3 Replies Latest reply on Mar 17, 2013 11:43 AM by disabled_ScottKoontz

    Making Changes to a DB once uploaded to a Server


      Hi all,


      What is the best and safest method to make changes to a DB that has been uploaded to a server? and is being utilized, as there seems to be always something to tweak...


      & what is the best method to upload a new DB to the server that is located remotely?


      Any pointers appreciated

        • 1. Re: Making Changes to a DB once uploaded to a Server

          Hi Mark


          I generally try and make changes after hours when the client is not actually using the system, always ensure backups are in place, and document and test all changes that I make. Then I inform the client of the changes made, and ask them to notify me asap if they notice any problems the next morning.  In a worst case scenario I could always revert to the backup, but have never had to.


          The majority of my clients have been using a Mac server and I usually have access to some (or all) of the client machines, so if there is a lot of data I use Apple Remote Desktop (or RDC if it's Windows) to control one of the client computers running FMP and use that to import the data into the new database. If it's a reasonably small amount of data I will transfer the entire database to my computer (from the clients server), do import that data into the new solution and transfer it back.  I use filesharing or FTP to transfer the files.



          • 2. Re: Making Changes to a DB once uploaded to a Server

            Thanks ChrisPye, will do...regards Mark

            • 3. Re: Making Changes to a DB once uploaded to a Server

              We make changes all the time to live DBs, and I can't recall the last time I may have created a problem, big or small, in making changes while live and used. Of course we check that backups are current and working, and sometimes make an ad-hoc backup before the big changes, yadda yadda.


              Layouts and scripts can be made at any time, and rarely have an unintended consequence even if a user is looking at the layout at that time.


              We change field defintions all the time as well, and about a year ago thought I caused a problem by changing a field definition on a live file, but I was wrong (it was some other scripting issue). I woud guess that it's been well over 5(?) years since I've seen a problem in changing field definitions. We sometimes take a look at the number of concurrent users when making a major change. Yes, I realize that others will tell you to wait until all users are off, but with users across 6 time zones and no known problems in over 5 years, we'll take the slim odds that we'd have to revert to a backup over working every late night and early morning.


              Adding and relating new table occurrances have also been shown to not cause any problems. We even go as far as changing existing relationships, but again some will caution you to avoid this.


              We upload new DBs (even large ones) using the Admin Console, almost every time unless it is huge in size. In the time that it takes you to zip a local file, upload to another computer (usually the server itself, and you need access and mapped ports), share the screen (access, mapped ports), unzip, launch the admin console, upload... you may as well have sent it from your laptop and assure the file includes everything including container info.