Separating interface and data

[StefanV]

Hi, while I'm new to FM, I am experienced in "older" database programming. So "only" the interface is new to me.

I've written an application and we could start data entry. As I will keep on developing the interface, I need a (easy:) way to update the application while keeping the existing data intact after.

From my research, it looks like I should separate my interface files and data files. But by now I have 48 tables in my application with many more TOs and relationships. So I looked if I could copy the whole file and relink the interface from one application to the databases of the other. While I can import the other "external" databases, that leaves me without relations on the new files, and the existing application remains on the "original" databases with all the layouts linked to the wrong (original) files.

Is there a good way of separating the two, or do I have to start back from scratch, which would be discouraging after this much work.

Or,... Keeping both data and interface in one file, can any one get me going on a script that would allow the data-update from the "old" file? I hear its all about "copy all data from old file to new file" and "update the counters for automatic field entry". Any more pitfalls I need to be aware of?

Thanks,

Stefan

[bcooney]

This approach is called within the FM community, the "Separation Model." It has a forum devoted to it here. Some swear by it, others not so much.

[Vaughan]

Some swear by it, others not so much.

Some swear AT it. :D

[IdealData]

Or,... Keeping both data and interface in one file, can any one get me going on a script that would allow the data-update from the "old" file? I hear its all about "copy all data from old file to new file" and "update the counters for automatic field entry". Any more pitfalls I need to be aware of?

That's the way I do it. The separation model is great in many ways but often I find that I am updating the table schema and the interface to achieve new functionality so the separation model gains me little as I still have to import records from the data file any way.

1. If you are storing containers then put them in a separate FILE to reduce storage in the primary data file.

2. The scripting import routine is roughly..

Delete all records in all tables in the NEW file

Open the OLD file

Find all records in all table in the OLD file (run a script in the OLD file)

In the NEW file Import all records from the OLD file to the NEW file

Update the next serial number in the NEW file

Perform any data "fixes" if there are fields that have changed the way they behave. For example, auto-entries that have changed content.

The above assumes..

The OLD file is based on a previous incarnation of the NEW file

The OLD file already has a script to find all records in all tables (it will do if it existed in the PREVIOUS NEW file)

Both files should have a set or "root" layouts and "root" table occurrences for each table

The OLD file must be specifically named

The imports DO NOT update serials and auto enters

Import by MATCHING NAMES

[comment]

Open the OLD file

Find all records in all table in the OLD file (run a script in the OLD file)

...

The OLD file already has a script to find all records in all tables

Why not simply keep the old file closed?

[IdealData]

Why not simply keep the old file closed?

Yes it's not necessary. I actually meant to say:

Run a script in the NEW file which will open the OLD file, and not as a separate procedure as it would appear.

Still, superfluous to requirement.