Seperation Model. What is it about?

[overrider]

Hello all,

i had to edit this Post. After several reads i came to realize i misunderstood the concept of seperation. now the question is; what benifits exactly does seperation of gui and data bring? easy modifieng of gui without interrupting the db? Or also some stability and robustness?

anybody know?

regards,

Overrider

[RalphL]

As I see it, the purpose is separate the Data from the Business Rules ( Calculations, Summaries & Reports) and from the User Interface. Thus there are three files. Changes to the business rule or interface can be made without having to import all the data into the revised database.

I have posted some sample files in this section.

[Westinghouse]

"I have posted some sample files in this section."

How do i get to those files ? I'm a new guy !

[RalphL]

Look at:

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=1175520&an=0&page=0#1175520

and

http://www.fmforums.com/threads/showflat.php?Cat=0&Number=122350&an=0&page=0#122350

[ĸupiэȶƺ]

Hello all,

i had to edit this Post. After several reads i came to realize i misunderstood the concept of seperation. now the question is; what benifits exactly does seperation of gui and data bring? easy modifieng of gui without interrupting the db? Or also some stability and robustness?

Well, obviously having several tables in one file brings many advantages. Let's say you have a solution with 25 tables. It makes sense to have all of them in one file, because then you can write one set of navigation scripts instead of 25, it makes working with the many relationships necessary much easier, etc.

But this has one significat drawback. Let's say you need to change the structure of one of the tables (new fields, revising calculations, etc.) In many envirnments taking the live file down for the legnth of time it takes to make the changes is not feasable, so you must do the work on a clone and then import the live data from the copy running on the server. If you have 25 tables in one file, you're going to have to do 25 imports into the clone file. If you keep all the layouts and scripts in one file, but have each table's data in its own separate file, you only need to do the import for the file containing the table(s) you modify - the rest of the 25 can stay untouched.

I for one am still getting my head around the separation model - it seems perfect for related databases that do not have many cross-calculations between them, but I haven't figured out all the ramifications it will have on creating calculations based on related values. Seems like it gets a bit messier in that case. Haven't experimented fully with the best way to tackle it yet, whether it's best to A.) keep all the calcs in the master file with the layouts & scripts, which means all calcs will necessarily be based entirely on related values, which seems inefficient; or B.) keep the calcs in the separated data tables, which mean a somewhat complex system of file references and relationships must be set up between the various files of a large system, analagous to how it's been done in the pre-v.7 versions of FMP. Obviously this works fine, as it has for years, but it means you have sacrificed the elegance and "cleanliness" of design v.7 has made possible.