Let's address the most seductive option for a database file currently hosted over the network:
Can you connect to the database via a full access password and make design changes to the file?
That would be (IMO) a qualified No.
The "best practice" answer you will typically get from TS personnel that work for FileMaker is that you shouldn't do it and they have very good reasons for recommending that. The reason is that if you make a design change to the database and a "network glitch" happens just at the moment your change is saved (committed) it can damage (corrupt) your database file.
To that, I will add that many design changes will "lock" all other users out while the change is being saved and in one case you can lock them out if you just open Manage | Database and open Specify Calculation for an auto-entered calculation.
Even without those issues a sudden design change can confuse the users when a layout suddenly looks different or a script does something new.
But I "qualify" that no, because I actually do make some design changes right in the "live" database.
a) I have a full back up system in place
b) I only make certain "low impact" design changes, such as creating or modifying a script or a layout. I don't touch anything in Manage | database.
c) Any design changes with directly affect users are at least "rehearsed" on a copy and/or tested on a duplicate of the current layout before making the change "live".
So most significant changes would be made to a copy of the file which you'd then upload back to the server. But this creates problems. The data in your new copy will not match the current hosted copy as changes were made while you developed the new version. At the very least, this requires that you close the current copy to "freeze" it from data changes, import all that data into a clone of your development copy and then you upload the new copy to your server. This can be tedious and require careful attention to details--such as updating auto-entered serial number fields in the new copy to avoid creating records with duplicate serial number values. But this can be scripted to reduce operator error and make it go more quickly.
And a key way to reduce the number of times that you need to import data when you are deploying a new version, use the Convert to Seperation Model technique with your files split into an Interface File and a Data File. Design changes made to the interface file will not require importing data and so you can simply replace the old file with the new to deploy a new version. Only changes to the data file will require updating.
Thanks Phil!! This was exactly what I was looking for. One other question. In terms of performance accessing the FMP database over the internet. Is it better to have the "interface" file local for each user or also stored on the server. I am not sure if local for each user could cause unexpected errors.