I'm not trying to say this is a bad idea. I'm just pointing out a challenge to making your DB work:
FileMaker scripts tend to be very solution, table occurrence and layout specific. It takes a lot of careful scripting to minimize that specificity so that such a scripts can be truly portable. And it can be impossible to fully remove all such specific references from a given script. You have some features such as GetField, GetFieldName, Set Field By Name that help you make a script portable, but there is no such equivalent method available for Go to Related records, for example.
Thus any scripts you import from such a source are likely to contain errors in need of correcting immediately after the import.
Guess I'll have to think of another way to store techniques I learn from this site and elsewhere.
I'm working on several different databases and - thanks especially to this site - I've implemented various techniques but when I want to reuse them, I can't remember which database or which script contain the techniques.
Unfortunately, it's not as easy as copying the script steps and pasting into an Evernote note (or similar) with comments. I can't be the ONLY person with this interest can I? Or, am I showing that I just have a lousy memory? :)
Actually, I think such a DB can be made to work. I'm just pointing out that you will need to do so with care. You may want to use text copied from a DDR report and pasted into a text field to fully document the script and assist in correctly importing a script into a new file.
There are also a number of third party developer tools that you may want to evaluate to see if they offer more than you can get with just FileMaker Advanced.
Thanks, Steve. I downloaded a demo. A Google search found a few similar products but this in the only one that explicitly mentions FileMaker 13. All the others stop at FMP 12. I like John Osborne's training videos which is a plus for this one, too.