Has anyone had experience with the separation model, I'm currently using a modified version of the scheduling application and am finding that I have to do quite a lot of changes, new functionality, new reports and layouts based on user input.

Then there is the dreaded export/import that has to be done!!:-(

From what I have read the separation model is ideal for rolling out updates, new layouts etc..

Regards

Roy

The separation model does make a lot of stuff easier: we use this in almost all our custom work.

However, you have to be realistic about what it can do for you. You can rarely roll our sophisticated new features by manipulating the interface file alone; in my experience, most new features require some changes to the date table (auto enter calcs, new summary fields, unstored calcs to use as summary break fields, etc.)

The good news is that it is pretty easy to split something like SeedCode Calendar into a separated state with an interface file and one or more data files. Give this a try on a backup and you'll see what I mean.

John:

My copy of Seedcode Calendar is already filled with data. I'd like to try separating data from interface as you describe in this post. Would I do this by creating a copy of my Seedcode calendar (call the original Cal1 and the copy Cal2, and assume I use Cal1 as interface and Cal2 as data)? Then, in Cal1 I could create a file reference to Cal2, and I guess the next step would be editing all relevant relationships in Cal1 so that they "point" to data tables in Cal2.

Is this correct? It would certainly require a lot of editing of relationships. Is there any easier way?

Yours,
Jim Recht

That is the way, but you'll find that you don't actually have to "edit" the relationships. You simply double click on each table occurrence that will now be from the data file and tell it that instead of using, for example, the Appointments table in the interface file, it should use the Appointments table in the data file. (Make sure you keep the table occurrence names the same.) Since the tables are identical the relationship matches will be maintained.

The graph in the interface file gets all done like this. The trick is that you need some kind of graph in the data file as well: a smaller, simpler graph to support unstored calcs, auto enters, and lookups. You don't need the presentation side of the graph (the month section, for example) but you do need relationships used in the calcs and auto enters of the appointments table. Most people end up with a bigger graph in the data file than they need. Again, something like Inspector can make it easy to get the graph down to just what is relevant.

FWIW, you can also script your imports and exports if the whole purpose of separating is to make new versions easier. Perhaps writing some scripts to import data from older versions and increment serial numbers is all you need.