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.
Thanks ChrisPye, will do...regards Mark
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.