Basic Seperation for newbies...please

[Dan-A]

Where do I start...

I want to keep data seperate from UI. I have a Purchase Order solution that worked on FM5 as follows.

Header (file contained POnumber etc..) - linked to LineItem on POnumber

LineItem (file contains info for each PO lines)

etc..

Now if I want this data in one file (say DATA_Module) and want to create a UI_Module file for all the layouts, how do i link to my POnumber from the new UI file??

In the older version i just had a layout (based on the Header file) with my fields and I would just enter the new POnumber & off I go!!

Now I'm not sure what to base my layout on since the fields I want are in another file.

Thanks for the help

--Dan

[RDecker]

> Now I'm not sure what to base my layout on

> since the fields I want are in another file.

You first have to tell the UI file what files are part of your solution (File/Define.../File References...). Then you need to add the tables to the File/Define/Database.../Relationships window and draw the relationships between your key fields. Then each layout in the interface file is assigned its own table (Layout/Layout Setup.../Show records from...).

Takes a while to get the hang of this new option, but once it clicks, you'll go quite quickly. I asked a lot of dumb questions when I first started, but it seems easy now.

[Dan-A]

Thank you!!!

I was missing the bit about "show records from..."

Thanks again for the push in the right direction.

I'm sure I too will have more dumb questions as I re-design my FM solution.

[Guest]

My application is pretty well developed and is NOT separated. Can I 'import' the layouts from the single file into the UI file?

Thanks

Ron

[Guest]

Separation sounds good in the immediate. However, when considering that while FM keeps several tables in a single file (one for date and calculations) and another for the User Interface (relationships, layouts and scripts) when it comes time to send end users an 'update' how do you replace just the UI Table in the application?

Yep, I am new to FM. Would like more experienced thoughts on this. Thanks

[Vaughan]

Jusr send them the new "interface" file. It should work, as long as the existing data file has the same name.

I've done a Test system with separate data and interface files. I found that to get auto-enters and lookups to work, relationships needed to be in the data file. Am I doing something wrong?

[Fridolin]

Hi!

I'm working with separating UI and DB rigth now. Found that it only work to a certain level. Looks like I'm ending up with this:

Data file = a lot of fields (text, number, date, calculation), some relationships, no scripts and no layouts.

Interface file = no fields, a lot of relationships and many layouts.

Business logic (eg. reports) = some fields (calculations and globals), many relationships and layouts.

My goal was to have all the calculation and global fields in the business logic file and no relationships in the data file. This seems impossible because every thing but globals need a relationship. Now I decided to go with only two files, data and interface. Major benefit is the ability to create a new environment for different groups of users, for example "sales", "service", "administrator" etc.

if anyone have insight how to take this further, please post.

Regards!

[RalphL]

I perfer the 3 file system, but I limit the data tables to data (Text, Number, Date, Time, Timestamp & Container). Few if any relationships & NO calcaulations or summary fields. I have been including a standard layout for each table.

The business logic file has a table for each table in the data file plus a globals table. These tables have the calculation and summary fields. This file has layouts for reports. Relationships as necessary to perform calculations for the reports.

The interface file has no tables, Has all necessary layouts and relationships to make the interface work.

Are you considering a separate interface file for each of the different groups? If so, you may also want to consider a different business lodgic file for each group.

[Guest]

Hi! Could You tell us more how You manage to place all calculation fields in the business logic file. For instance; in UI You often want a summary field below a portal to guide the user.

Regards / Fridolin

[RalphL]

In the BR file each table has a serial number field that equals the serial number of the table in the Data file. The calculations use values from the related fields in the Data tables. I use the sum function which is placed under the portal to show totals in the Interface. The interface normally has no tables of its own. Layouts use a TO for a table in the BR file.

Look at the sample files under Speration Model for Many to Many Relationship

[Gambler]

Data seperation is not new to other RDBMS, only to FM. As a relatively new FM person, it has always troubled me the way FM developers like to "stuff" everything into a single file. Most other RDBMS break items into

Tables -- the basic layout of where the data is stored (the user doesn't see this).

Forms (or Views) How users actually see the data.

Queries (Procedures or scripts) programming that acts on the data based on all sorts of different criteria from a user's security level to whatever.....

Relationships between the data tables.

FM always seemed to be a little less than a true "real" RDBMS. Version 7 gets it much closer to the accepted database design concept that one might encounter in Oracle, SQL, INGRESS, etc.....

Seperation may be challenging, but once you understand the concept, you will appreciate its simplicity and design better applications. FM 7 is very good.

[Roy Osborn]

New to this concept in Filemaker. Can I just think about file references as "instances" of tables. What is the advantage to seperation of calculation fields & summary fields from the other data that it directly relates to?

[Roy Osborn]

I think I just answered my own question. Calc and Sum fields need to be seperate because the depend on the impementaion of the relationships--obviously. One could even create several versions of the Business Logic file to test different assumptions!? This could come in real handy at Fanny Mae!

[clifford]

I think one of the attractions of fmp7 is its ability to put multiple tables in one single file. I've found multiple files don't work properly with instant web publishing.

Data separation may have its place in large dbms systems, but for most small business applications and rapid development, it makes no difference as long as the end result from the end user standpoint is the same.

Regards,

Clifford

[PatriciaW]

I didn't see an answer to this question ... but I just discovered that although an import function does not appear to exist, it is easy to copy all fields from the layout in one interface file, and paste the copied fields into a new blank layout in the other interface file. As long as the table occurrences have been defined in the database, and any relevant scripts have been imported (and possibly other things such as value lists) the new interface will be fully functional.