Obviously I can download the database file and make small changes and put back on the server during off hours when no one is using the database.
This is the safest and best way to make both large and small changes. Of course this creates a number of issues, but there are problems and risks inherent in making changes to a live, hosted database:
1) When you commit database changes back to the server, if you get a "glitch" at just the wrong instant of time, you can get a damaged database file. This risk is highest for the type of changes that you would use Manage | Database to do such as modifying a table's design, relationships or changing a calculation specififed for a field.
2) When changes to a table are being committed (by clicking OK in Manage | Database), the table is locked and no changes by other users are permitted until the update is complete.If another user is performing a script, this script could fail to update records and the results could be very ugly. Just opening the specify calculation dialog to examine an auto-enter calculation locks the table against changes until you close the dialog.
3) Any design change, even a layout change might catch users "between stools" so such changes should be made with caution and taking care to stay in communication with users as to ongoing changes.
Changes to layouts, scripts, value lists--interface level changes, have a much lower level of damaged file risk and most developers supporting a hosted file routinely make them while keeping in mind the issues previously listed.
One option often used is to make major design changes to a copy of the database and when you are ready to deploy, you save a clone of the database and then, during off hours, take down the database and use a script with multiple Import Records steps to import all the data from your older version into the new.
Also, a Convert to Seperation Model approach can be used to produce an interface file that can be updated without the need to import any data in the interface file. This can reduce the number of data imports needed to implement updates.
Thanks for your response. I was afraid that was going to be the answer. However, I think I will definitely look at the 'Data Separation Model'. Separating the the frontend from the backend would at least make it much easier to modify the interface.