Heathbo Posted July 20, 2007 Share Posted July 20, 2007 I have a file(A) with all the data. I want file( to be the GUI. With the two linked, do I have to have a record in file( for every record in file(A)? Or can I have one record in file( and view all the records in file(A)? Link to comment Share on other sites More sharing options...
The Big Bear Posted July 20, 2007 Share Posted July 20, 2007 Hi Heathbo The way I made my separation model is to enter data in table B and storage it in table A. To view the data in table b can be done in a couple of ways. To view all the records, use a portal in table B. To view a single records, I made a layout that resemble the input screen and use related fields to edit or view the data. When the users is finish reviewing the data and exit the file the record is cleared. So that is only one record in file B. Hope this helps Lionel Link to comment Share on other sites More sharing options...
mr_vodka Posted July 20, 2007 Share Posted July 20, 2007 All you really need to do is create a file reference to your data files. Then in your GUI file just create table occurences of the data tables. Its that simple to implement. You may also want to take a look at this thread by Ender. Separation Model Thread Link to comment Share on other sites More sharing options...
Heathbo Posted July 21, 2007 Author Share Posted July 21, 2007 But how do you browse through the files in the GUI file. When I push the next button for example, how does the GUI file go to the next record in the Data File? You can't use the go to next record command because in the GUI file there is only one record. Link to comment Share on other sites More sharing options...
Ender Posted July 21, 2007 Share Posted July 21, 2007 The Interface need not have any local tables (and therefore, no records). You can use the tables from another file as the base for local layouts, relationships, scripts, and value lists. They behave as if they were in the local file. Link to comment Share on other sites More sharing options...
Fenton Posted July 21, 2007 Share Posted July 21, 2007 Heathbo, you're forgetting that layouts, therefore fields on layouts, are based on Table Occurrences, NOT on the "physical" Tables (if we call any of this physical; I mean it exists on the disk). A Table Occurrence for a Table can be in ANY file which has a File Reference defined, which points back to the physical file and table. A Table Occurrence will behave in almost all respects the same no matter which file it is in. Of course, if you need to define a field, you must go back to the "real" file; and any relational connections within its calculation fields must exist in the real file. But almost everything else uses the table occurrence. Link to comment Share on other sites More sharing options...
Heathbo Posted July 21, 2007 Author Share Posted July 21, 2007 OF COURSE! Why didn't I think of that? So all calculations and relationships have to happen in the Data File not the GUI File? If thats the case, what's the point of this model? I was looking for something where the Data File holds just the data. The GUI File holds the relationships and calculations. That way if I have to make updates, the end user doesn't have to reimport their records. Link to comment Share on other sites More sharing options...
Heathbo Posted July 21, 2007 Author Share Posted July 21, 2007 To add to this, using this model, how would I set it up in this scenario? File(A) is the GUI File = The GUI File(: is the Personal Records = All DVDs you own. File© is the Data Files = File where all possible DVDs are stored. Basically, you browse the Data Files and Personal Records through the GUI file. You add records from the Data Files (through ID# ?) to your Personal Records. Link to comment Share on other sites More sharing options...
HarryGlos Posted July 21, 2007 Share Posted July 21, 2007 Hey Heathbo, If you don't mind my making a recommendation, it would be to go to the following thread http://fmforums.com/forum/showtopic.php?tid/184392/ and read all of the posts. It's right here under "Brain Food" just under your post. It will not only answer your questions, it will give you a much better overview of how things are done with the Separation Model and why. It my well be a good half-hours reading but it will put you where you need to be. Unlike me, you'll hear from people who really know what they're talking about! : So check it out and tell me if I'm wrong... Harry Link to comment Share on other sites More sharing options...
Fenton Posted July 21, 2007 Share Posted July 21, 2007 Heathbo, there is a further extension of the separation model, which uses 3 files, a data file, a calculations file, and an interface file. The Calculations file has at least the IDs of the Data file. All record creation is scripted so that the Calculations file gets a "mirror" record with the ID. The Data file is then available to it via relationships, to access data for calculations, which can then be seen by the Interface file. Maybe the data fields referenced in the calculations are also mirrored and updated in the Calculations file? I can see how this could be done, using an "events trigger" plug-in. Otherwise they would not be indexed (at least what it seems like to me). But I really don't know; I have never worked on such a solution. I can see its use however, in a distributed solution, where you would not have access to the Data file, and where there were large amounts of data involved. I have seen discussions of this method, but they are all mixed up with other separation model discussions. I would also think that you'd want to understand the 2 file SM method pretty well before moving on to a 3 file one. Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 6116 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now