I studied Matt Petrowskies video on his filemaker magazine site Contacts,Companies, Details.

I want to use his internal separation model to build a contact manager but am not sure this changes things with the new Filemaker 8.0 Advanced.

He has a separate interface table, with tables for companies, contacts, companyDetails and contactDetails in his sample file.

As I understand this video, the reason for the interface table is to control the menu options that a user has available to him in other words get rid of all menu options especially delete and replace. If this is the case, then with Filemaker 8.0 advanced does that mean you no longer need a separate interface table? You would only need the company, contacts, company_details, contact_details tables without the interface table?

Is there any other reason that a developer would need the interface table? I believe he also stated that it is easier to read the relationship graph if you do it this way. All the interface layouts are in the one table which makes sense.

With FM 8.0 Advanced you could take away all the menu options and I suppose use the Company table to include the interface layouts? In this way you could still use Filemaker menu items in scripts in the company table or you could allow some of the menu options so I assume development would be easier? For example, it would be easier to script the "new record, delete record, search etc" commands in the companies table than in the interface table.

The other question I have is: I converted a db Filemaker 6.0 --> 8.0. My plan is to fix the db in 8.0 the users are now using and develop a new interface and database alongside.

So this new interface would be a separate table and I can envision how to point the file references from this interface table to the old database. If I don't use an interface table(see my question above) then do I use the company table to point to the old company table directly?

Thanks for any advice on question 1 or 2.

Edited September 17, 200520 yr by Guest

Hi Janis,

I think the main purpose for a separate interface file is to make it simpler to update the interface. For example, if you are a developer that sells the same basic solution to multiple clients, you can add a new report or add a section to the interface file, and simply substitute it into place in each client's system to make the change come to life. I've also seen a solution where, for speed reasons, the interface file was kept local to each client workstation, but the data files were stored on the remote server.

I don't think FM8's ability to control the menu options changes the decision to use the Separation Model.

On the other hand, your thought to use a separate interface file as a method of upgrading the interface from the FM6 model to one that takes advantage of the new features of FM8 is valid.