There are two methods developers routinely use. You've hit on "method 2". "Method 1" reduces the need for "Method 2" but it is still needed from time to time so it is a good idea to structure your database to support both methods.
Split your file into two files. File 1 stores all your data tables. File 2 stores the interface--the layouts, scripts, value lists etc that control what the user sees and interacts with when using your database solution. With the system split like this, most updates can be deployed to your users by simply sending them a new interface file. Since the data file is left unchanged, they don't have to import any data and can just replace the old interface file with the new copy.
See this link for more on this: Convert to Seperation Model
Sometimes you have to change the design of the data file and then you have to import the data from the old file into the new. Before you deliver your files to the customer, include a "prepare for update" script that moves from layout to layout whild doing a Show All Records on each layout until this has been done for every table in your file. Then, when the time comes to deliver an update, create an import script in your new data file that performs this "Prepare for update" script in the original and then imports data from each table in to the new file. Your script should also include code that updates the next serial value settings on any serial number fields so that no duplicate serial numbers are generated the first time the user creates a new record after updating their solution with your new file.
Ran into a bit of a snag with this. All was working fine, I got the tables split off from the layouts and scripts. But now, when I add a record, one, I can no longer navigate to it using a script to go to related record. The record seems to show up in one portal just fine, but I cannot delete the portal row now. What do you think i broke?
Deleting a portal row does not require Go to Related Records so I'm a bit confused by what you describe here.
Being able to delete a portal row is a setting you control with Portal Setup...
If you use Go To Related record to pull up this record on another layout and then delete it, (Do this with extreme caution or you may end up deleting records from a completly different table!) you'd need to look at the layout names and table occurrence names specified in the Go To Related Record step to see what has changed.
I am trying to create a custom access profile. I have split my database into two files. One for the Interface, Layouts, Scripts, etc. One for the Tables (Records). Now when I attempt to reduce some of the access for one of the user accounts, I will not access any of the table in the external file. I want to restrict access for one user to one specific area of the database and basically two layouts. The initial Home screen layout, and the layout that is to access one table of data. As soon as I do this, it fails to see any of the tables. I have a feeling there is something special about granting access when you have data in an external file, but I can't seem to figure it out.
With you files, you have to manage access privileges for both files in concert. When you open the interface file, references to the data file will cause FileMaker to open that file and it will attempt to open the file with the same account name and password used to open the interface file, but the privilege set you define in one file is separate from the privilege set you define in the other. Thus, in your shoes, I'd check for any inconsistencies between the security options specified in privilege sets of the interface and data files.