- Because I want to keep the possibility of upgrading the software with new features, I would rather have the databases outside of the application. When I create a stand alone app in FM Pro Adv, will the software extract the DB (if any built in) and save them outside of the file or should I create some external relationships?
FileMaker Advanced will create exact copies of your development files. If you want to split your system up into multiple files, you'll need to do that with your development files before you create the run time.
- Should I have one file for each table (clients, stores and salepersons) or one file with multiple tables?
Take your pick. There are trade offs. It's a little simpler to deploy an update of a single table file, but it complicates the design and function of your DB a bit.
- Any way to have a script inside FM Pro that would create a backup of all necessary files every so often?
Yes, it should work with a runtime, but I haven't tested it to be sure. A script can use Save a Copy to save a copy of the file to a filename you specify in a variable--which allows you to include a date if you want successive backups of the file.
- If one of the external files do not exist, is there a way to run a script that would create an empty one from scratch? Or maybe, should I keep some empty ones in FM Pro and just have a script export it to an external location?
You can use Import Records with the new table option to import a table with all it's field definitions into a different fileMaker file. You thus could open a brand new FileMaker file and use Import records to pull in the table. Any calculations defined in fields that reference data in a related table will be inclosed in /* comment brackets */ to disable them until you edit their definitions to fix this after import.
- Somebody mentionned that the database created in FM Pro were protected with an algorythm based on the user name and password. Is there a away to also protect the external DB?
That's a new one on me. you can define an account name and password to protect any FileMaker file. If you define identical account names and passwords on all your files, you can open one file with said account name/password and then Filemaker can open all the other files as needed with the same account name and password without popping up a password log in dialog for each such file. Managing all those identical account names and passwords for multiple files are one of the main drawbacks to splitting up your solution into separate files for each table.
- Anything else I should be aware of?
One approach is to split your system into just two tables--one for all data tables and one for all layouts, scripts etc. That approach allows you to deploy most updates simply by having your client just replace the interface copy with the new release.
You can also create an update script that imports all data from all tables, into the new version and which also updates all serial number fields to the correct next value settings. You can set this up so that the client simply has to click a button and then select the file that they are about to replace with the update from an Open File dialog.
Runtime solutions can't do everything a regular installation of FileMaker can do. Make sure you research the limitations in the included documentation before committing to the runtime approach.