Even with MS Access, if you had to make changes to the data half of the solution, you had to import the data from the original file into the new. That said, using a data separation approach reduces the frequency with which you have to import data from one file into another in order to deploy a new version by quite a bit.
Here's a link on how to split a FileMaker file into data and interface files: Convert to Seperation Model
In cases where you have to deploy an updated copy of the data file, you can set up a script that imports all data from all tables into the matching tables in the new file and which also updates any serial number fields to be one larger than the largest value in the serial numbers of the imported data.
In the meantime I was able to upload and remotely access the program and speed doesn't seem to be an issue.
With the server properly set up and using the open-remote in filemaker pro, I was able to enter the ip of the server and wham, I was in and working!
If your friend is hosting on FileMaker Server then you can make changes to the live files without too much concern. FMS can handle losing a client, even from having to force quit your side. Always perferably with users out of the file while you are working on it. One of the strong points of FMS is its backup capability. As an admin you can create a backup right before you start and as long as no one else is in the file changing data, should the worst happen you can switch out the two files.
If your friend is hosting the file on a regular copy of FileMaker Pro then I would close the file on his server, download it to your computer, make your changes and upload it to the server when finished. You didn't say what platform you are on, but from the mac side Chicken of the Sea and Cyberdog greatly ease the process.
Changes to Manage | Database will lock entire tables while the changes are committed. If a user runs a script while the table is locked in this fashion, it could, if set error capture is enabled, silently fail to update data with potentially disasterous results. Even opening certain dialogs in Manage | Database | fields just to inspect (not change) what's there will lock the table until you close the dialog box.
If there should be a network glitch while making such an update, the file can be corrrupted. I've seen cases here in the forum where a file was apparently damaged by such an event, but the users did not encounter issues with the file until many weeks of use with many backups had been made.
That said, I do, very carefully, make small changes directly to the file, but these are usually adjustments to the layout or a script--not a 'structural' change to the database. If I do make a change to a table, I only do so when I am absolutely sure that no other users are accessing the database--such as early in the morning before the business has opened for the day.
Somewhere around 7 or 8 FileMaker Server was being touted for a capability of allowing developers to safely work on files while being served. I don't know if they tout that anymore, but there are still a lot of us who, if we are going to get any work done, have to work on live systems whether at the client's office or over the Internet. Since those days I have made lots of changes to lots of FMP databases, including schema, tables, relationships, etc. while being served, I have yet to kill a file or even corrupt it. That said I always have multiple backups.
Is this the best practices, maybe not, but works and seems to work quite well for me and others. In episode 186 of FileMaker Success Tips this very subject was covered, one host works my way and the other more like Phil.
As always your mileage may vary.