Data/Interface Separation Discussion

While at the 2007 annual Developer's Conference, I met up with Brian Loomis from Virtual Relations and Ross Mackintosh. We had a short discussion about the benefits of using a Data/Interface separation model. In the past, I've not heavily promoted this model of FileMaker use - however, after this discussion I may just start using it myself.

If you don't already know, Data/Interface separation is using at least two files for your solution. One file is for data storage and the other for the interface. The separation is quite common in the rest of the computing/database world. FileMaker is actually quite unique, in that, both the database and interface are all within one file.

There are many issues with importing/exporting when considering the upgrade process tied to a single FileMaker file. The advantages and disadvantages to the multiple separation models possible should be considered whenever you're converting or starting a new FileMaker solution. Brian helps you understand the possibilities available.

Comments

Ever since FM7 this I have had one problem with the separation method with FileMaker. The aggregate functions applied to a calc field don't update while performing record additions inside a portal. What I mean is if I have set the portal relation defined in the interface file ,which allows the creation of records via the relation, it will not calculate any of the aggregate funtions based off the portal records.

Example:
Invoice and Line Items, 2 table. I want to add records to the line items table via a portal which exist on a layout based on the invoice table. Each record added to the line item portal has a price field. I Have established a calc field based on the aggregate function 'Sum' which will add up all the prices of the records in the line item portal.

This all works fine until you separate the fields into a data file and display the data through a separate interface file. That sum field will not recalc as you add records to the portal until you exit the portal, such as clicking outside the portal.

I hope I have exampled the problem well enough for someone to understand. I can always send a sample file too.

Now since the guys at Virtual Relations say there are no disadvantages with the separation method, I assume they have figured a way to fix this. If so please let me know. This is the only reason why I don't use this method.

Great video and thanks

While this is an interesting video, I'm afraid it does not offer anything about the technique(s) used to actually achieve the separation of data and interrface. While I have achived separation, it is somewhat complex and not a simple matter of having an interface file that one can just substitute for an older interface file. That would be great but I don't see from this video how that might be achieved. I'd love to see how to do that.

I'm glad that there is more interest in this. Unfortunately, we had only stolen moments during the FileMaker conference to create this video.

We talked a little bit about doing a series that will show exactly how to do this in great detail, hopefully Matt will invite us back to do a series that answers these questions and more that others may have. ;)

Brian Loomis
Virtual Relations

Additional and more in-depth information on this topic, would be very helpful.

Andrew

Good to see more people doing this.

This is very handy in a global/multi facility deployment of solutions, especially if users will be using other languages and interact with a central data source (only english for me so far for central data... interpretation in UI files) Not only can you create a central data source for external connections, deploy local UI files for link, but I deploy location specific (custom) UI files specific to each internal/external/franchisee/distributor client's needs that interact with the same data. We usually just host them though...make them / their IT deal with local stuff. /*bolster the liscense & up-sell custom apps*/

You list some cons of the client-local interface file without discussing any of the techniques that can completely mitigate it. Joe King is a master of this technique and has FileMaker native scripts to "push" a new interface file to a client starting with an outdated version. This certainly bears mentioning. It would be helpful to explore in depth the various nuances of a separation development model. It make take several sessions to cover all the issues. Thanks again for a great thought-provoking video.

Regards,

Theo

Hello and thanks for this interesting video and comments.

I also would love to have more details on implementing data/interface separation model, especially the "solution 2 model" (data file on the server side and an interface file on the client side)as described in your video here:
http://www.filemakermagazine.com/videos/data-interface-separation-discussion.html

Thanks