Splitting a Filemaker Database

[RodgerBell]

I have a database and I'm looking to split it up into a front and backend... IE one side all GUI, and the backend all data. Is there and easy way to do this in FM? The way it looks now I have to relink all my relationships and scripts! I have 60 some relationships and 100+ scripts all with file references. There has to be a way to do this?

Added:

Note: right now I just want 2 fm databases... one with backend data, one will all gui stuff

Edited December 2, 2007 by Guest

[Matthew F]

Try searching for 'Separation Model' for many more posts on this topic. Here's my own two cents on the issue:

I have done this on several databases that are of a similar scale to what you are considering. In the end I'm not sure that the extra complexity was worth the effort.

It is nice to have the primary data off in a second file. However you lose some functionality in scripts. For example if you have two separate databases, each with their own backend file then you won't be able to perform the "Go to Relate Record" script step.

Another issue is that the relationship graph usually needs to be recapitulated in both the front-end and back-end files because some scripts won't function correctly in the front-end file. This can be confusing if you make a change in one but forget to make a change in the other.

[Fenton]

On the other hand, many people feel that it is a good idea. I've done a bit of each. Personally I think the decision to use the separation model depends more on deployment and maintenance. SM facilitates enhancements to the UI when you do not have easy access to the files, and you need to often tweak the interface and functionality.

The separation is also good if you have a complex structure in place for the interface itself. I've seen SM solutions where the interface file had several tables used to produce a standardized interface, tabs, buttons, etc..

As mfero says, it starts to get more complex if you have more than one data file. But even this can be fairly easily handled, using global keys for Go To Related Record in the UI file. But it is one of things you'd definitely need to fix.

As far as converting your existing file, you can clone it, to produce the Interface file. Then retarget all the table occurrences on the relationship graph to use the Data file instead. This should reassign the layouts (and their fields) to the data file's tables. You can then delete the tables of the interface file, except tables being used for constants (depends what they are) and/or globals, which may as well stay in the interface file.

Then go to the Data file and (carefully) remove scripts (rarely scripts may still need to run in the data file, due to permissions).* Very carefully remove any relationships in the data file that are no longer needed. Remember than some fields, lookups and calculations need relationships, so those must remain.

It is only wishful thinking that having a SM means you never have to import data, nor that you will never need a scripted routine to do that. I think you can get around having to do this when you create a new field, if you can just get access to the data file and create it. But bad things may happen, someday; the files will be closed improperly. Having an automated import routine makes it fairly painless to import the data into a clean master copy. Best to be ready.

*I remember doing this for a Copy All Records subscript; but I can't remember exactly why; maybe I didn't try hard enough to get around it -]