I don't have answers for all your questions, but here are a few to get you started:
Should I be considering file-separation - Layout.fp7(Layout designs) Data.fp7(Data-store)
Yes, this will simplify things for managing updates as you can simply provide a new copy of the interface file to replace the existing copy for a large percentage of your updates.
How would I go about doing runtime updates without trashing users data? Is there a simple script that could be used.
For cases where you have to deploy a new copy of the data file, you can provide a script that imports all the records from each file and that also updates the next serial value settings on any auto-entered serial number fields.
How can I create a demo that users could use locking it down to say 10 records?
You can replace the new record command with your own script in a custom menu. This script can either count the records in the table or check a counter in another field to limit the user to a set number of records.
What is the recommended way to create a help file for the application.
Simplest option is to just add another table to your solution with layouts and scripts to facilitate searching out answers to text you enter into records of this table.
Thanks Phil, That gives me something to run with.
If I have already created the db and all my layouts is it easy to seperate them? Perhaps create a copy and rename it to layout.fp7 then remove the tables etc and then join the layouts to the original db?
It's actually pretty simple. You can make a copy of your existing file and then repoint the interface copy's table occurrences to refer to the tables in the other file, then start deleting elements from each copy to produce the two halves of your system.
Exactly as I thought. Many thbaks again Phil.
Well that was easy...Thanks.