Separation of Data and Interface

[N Hagy]

I have just begun work on a new database in FM7 for my company. It will be used to manage our customer relations which involves a number of

[Kurt Knippel]

Sadly that is a limitation of the current interface for adding fields. They are displayed in creation order.

[N Hagy]

Ouch! That

[Fenton]

I'm not seeing this right now. Mine match the field order. At least in this test file. Are you both upgraded to 7.0v2? Or am I just lucky?

[N Hagy]

Fenton,

I do have the upgrade. Are you viewing in the current file or from another file? When I view the fields in the current file in layout mode they are ordered the way I arranged them. But if I view the same fields (table) from another file they are displayed in the original creation order.

[Fenton]

Yes, this is in another file, with a plain Table Occurrence of the Data file. You know, I've also seen that problem, where the fields to choose from were sorted in creation order, even though they were sorted by name in the original file. But I can't seem to recreate the conditions, so I assumed it was fixed. Perhaps it's the OS? I'm on Mac 10.3.4.

A work-around would be to create the layout in the "data" file, then copy (cut)/paste it into the "interface" file. If you name the TO's the same it seems to know which field is which. It kind of defeats the purpose of the interface file to some extent. But you can use this for the basics, then delete the layout from the data file (though one may want to keep a basic fields layout there anyway).

[RodinBangkok]

Works fine for me also, using 7v2 and Mac 10.3.4.

Rod

[N Hagy]

Fenton, Rod

It must be the OS. I'm running Win 2000. Evidently this was not addressed with the Windows upgrade. Shame.

Fenton, thanks for your suggestion. That would be less tedious at the outset than trying to scroll and locate fields from the Interface file. I believe the separation approach will be worth the effort in the long run. I

[Fenton]

I wonder if it works on Windows XP? If it's any consolation to you, scroll wheels don't work on Mac OS X in FileMaker, haven't for a long time. We've got a few glitches also.

[DanBrill]

Nope. Running on XP and it always shows the creation order.

[N Hagy]

Well I

[Computer Geek]

It works for me both in Windows 2000 and XP.

[Heathbo]

I am new to the Seperation of Data and Interface concept. Is there a post, website, or whatever else I could look at to help me? Could someone come up with a real easy example that I could download and play with? I learn better that way.

Thanks

Heathbo

[Crag]

I'm not sure it's even possible to seperate data from layout in Filemaker yet. Are you saying it is?

-crag

[RalphL]

I posted a set of sample files for a many to many relationship. It requires the Troi Text Plug-in to work. The plug-in is not require for the separation model, it used to contol the uniqueness of the primary key in the join table. There are 3 files: Data, Business Rules & Reports, and Interface.

[Crag]

Where did you post these files?

[RalphL]

It is in another thread in this section "Separation Model. Look for "Separation Model for Many To Many Relationship.

[ĸupiэȶƺ]

A work-around would be to create the layout in the "data" file, then copy (cut)/paste it into the "interface" file. If you name the TO's the same it seems to know which field is which. It kind of defeats the purpose of the interface file to some extent. But you can use this for the basics, then delete the layout from the data file (though one may want to keep a basic fields layout there anyway).

I was about to suggest this very thing. Among the pleasant surprises in V.7 was discovering thislittle trick... in fact, you don't even need a table with identically-named fields in the interface database - you can use the data file itself, just create a file reference to it, and then create a layout in the interface fioe based on the table in the data file, and then copy & paste the layout in its entirety from the data file and it will work perfectly.

Another option is to develop several tables in one file, then save multiple copies of it, and reassign the tables on the relationship graph from the tables in the local file to the tables in the duplicate - this way you can "break out" the tables into separate files AFTER you're done developing the system. Sweet.

I'm not sure if I'm explaining this clearly, so here's an example. I'm working on a simple job-tracking system for a local manufacturing company. There's a main table with job data called "Jobs" and a related table called "Contacts" with contact information about the customer for that particular job. It's all in one file called "JobTracker.fp7".

Once I'm done writing the system, the last step is to duplicate the JobTracker.fp7 database, and rename the copy to "ContactInfo.fp7". Then I go into the original JobTracker database, set up a file reference to ContactsInfo.fp7. Then I got into the relationships graph and double click on each instance of the Contacts table in JobTracker.fp7, and redirect each of them to the Contacts table in ContactInfo.fp7. Then I change any layouts based on the Contacts table to use the one in the external file also. Lastly, I delete the "Contacts" table from the JobTracker.fp7 file, and delete the "Jobs" table from the "ContactInfo.fp7" file.

BINGO! A system created with all the development benefits of having all tables in one file, but which as a result of the last step has everything broken into separate files a ' la the separation model.

Depending on the structure of the system, it may be necessary to go into the new ContactInfo.fp7 file and setup a file reference to the JobTracker.fp7 file, and reassign all tables and layouts using that reference, before deleting ContactInfo.fp7's "Jobs" table. If you understand the process I'm describing, it's trivial.

[PRP407]

It seems like what you're talking about is making a clone of the working file (with or without data wasn't clear to me) and renaming the clone. It's a great shortcut to recreating a file with tables included but isn't necessary to using the separation model. My datafile has a layout for each table with no design and no scripts. My user interface has all the scripting, buttons, fancy layouts, etc. and gets to the data using file references and TOs. No data is stored in my user interface and it is a pretty small file. The data file is around 150 megabytes. So are we talking about the same thing?