First off, you should know that I am a total newbie to Filemaker.

One of my concerns with Filemaker has always been the issues surrounding updating apps... distributed apps. It appears that the separation model is an attempt to alleviate some of these issues; however, I've read in a couple of places that the separation model is no longer relevant.

Not sure what is meant by this, but I thought I would ask the question. Is the separation model ideal for those situations where you will need to update the solution on a regular basis?

The separation model is as relevant as it ever was. It depends on who you ask as to whether it was ever a good thing or not. :

IOW the separation model is a technique that trades effort and complexity in development for some ease in updating the solution later. It never completely solved all the problems -- for instance it only eases updates in interface not data structure -- and it introduces quite a few issues of its own, which is why it was never whole-heartedly adopted.

IMHO if you are a beginner, forget about it for now. Just build databases that work.

It think using the separation model depends more on what kind of access you have to the files (now and future), and what the general situation is. In many situations it is the only sane way to go. Many changes to files, especially established solutions, can be done entirely in the "interface" file. Scripts, layouts, and most relationship changes are in the interface file.

Yes, you'll sometimes need to add a field or relationship to the "data" file. But this takes much less time than the above. You can stop the files on FileMaker Server, make additions/adjustments, then put them back up again.

As far as issues, yes, there are a few. But almost all of them solvable. One of the worst is how to add Accounts which may have been created in the production files, while you were off working on a separate offline copy of the interface file. I have recently solved that, via a rather complex script, which captures "last time run", and attempts to log in with new or modified accounts (it stores the account & pw in a table, so not the most secure), deleting/creating as necessary. It was pretty much a PITA build, but it works and solves that problem (there are hundreds of accounts for that client, so manual was not cutting it).

We would have been paralyzed without separation of data in that situation. But with other clients I did not do that, as I had much better access.

So it sounds like the key is "access". If you have access to the DB then it's not that big of a deal, but if your remote, as I will probably be, then it could be a life-saver.

I've checked a couple of books and none of them seem to address this potentially life-saving (lol) technique. Is there any resources out there to guide one into the separation model?

Of course, I will follow Vaughn's advice and just "make db's" for now, but most of the applications that I create are distributed desktop apps, so eventually I will need to be moving that way.

Thank you for the replies.