8 Replies Latest reply on Jan 29, 2014 1:42 PM by nickalex

    Separation and Relationships

    nickalex

      Hi, all, am I correct in assuming that when using a separation model the relationships in the Data.fp12 are irelevant...ie only the relationships in the ui.fp12 matter, as they're the ones that are used by the Layouts which are all in the ui.fp12 ?

        • 1. Re: Separation and Relationships
          PSI

          In it's simplest form the relationships in the data file are required for Calculations and Lookups. This is because the field resides in the respective table in the data file in order to create a subtotal or a lookup that has to be defined in the data file. Some developers also setup cascade deletes in the data file as well.

           

          John

          • 2. Re: Separation and Relationships
            Mike_Mitchell

            Be careful with the cascading deletes. If they exist in any of the files, FileMaker will enforce them. (Found that out the hard way. Had them in both interface and data files; turned them off only in the data file, thinking that would stop it. Didn't.)  

            1 of 1 people found this helpful
            • 3. Re: Separation and Relationships
              nickalex

              Thanks, John ... does that mean, though, that if there are NO relationships in the data.fp12 but the relationships DO exist in the ui.fp12 then the Calculationships and Lookups will actually still work ?

              • 4. Re: Separation and Relationships
                PSI

                No the only relationships "needed" in the data file are for calculations and lookups.

                 

                to clarify the basic design...

                Data file - all tables for the solution. Customers, contacts, invoice, invoice line items etc...

                UI - no tables are required but I usually have one table with global fields for doing reports

                 

                Lets say you want to lookup the customer name and address to an invoice. You define a field in the invoice table for each value. you setup a relationship between invoice and customer base on the customer ID. so that relationship needs to be in the data file.

                 

                make sense?

                John

                1 of 1 people found this helpful
                • 5. Re: Separation and Relationships
                  nickalex

                  Well, yes...and No...because to date I've always designed the data basic structure within data.fp12, like the simple one-to-many relationships but when I need any alias tables I always put them in the ui.fp12 ... am I headed for trouble ?  Globals I always store in the ui.fp12 as they're likely to change with new versions, and (hopefully...yeah, right) the data structure is pretty stable except for additional relationships that I put in the ui.fp12...seems to work fine...

                  • 6. Re: Separation and Relationships
                    Malcolm

                    I've always designed the data basic structure within data.fp12, like the simple one-to-many relationships but when I need any alias tables I always put them in the ui.fp12 ... am I headed for trouble ?

                     

                    That sounds like you have the right idea.

                     

                    Your data file only needs the relationships that are necessary for data. This is driven by the definition of your fields. Does a field need to be linked to another table? If so, provide a relationship, otherwise do not bother.

                     

                    Your UI file will typically have a much more complex graph because you want the UI to provide all sorts of interesting feedback. The SQL commands reduce the need for UI relationships, so the UI graph can become much simpler too.

                     

                    Malcolm

                    • 7. Re: Separation and Relationships
                      CarstenLevin

                      Hi Nick,

                      Assuming that there are only two files in the solution

                      • solution_data with the tables
                      • solution_ui with the userinterface, session tables etc.

                       

                      The answer is either Yes or No to your question.

                       

                      The answer is yes there should be no TG's in the datafile

                      If you choose to use the model all the way through, and are not using calculation fields etc. etc. then you will probably only have those TO's in the data file that are needed for creating accounts etc. etc.

                       

                      The answer is no, we will have TG's in the datafile

                      I am strongly proposing separation and keeping all functionality in the UI file and only basic functionality in the datafile. But FileMaker is FileMaker and I suggest that you do not stop using calculation fields. And using calculation fields will imply having at least some basic TG's supporting the calculations in the data file.

                       

                      If you are going for separation for principal reasons, then you will go for "Yes" to your question. But if you want the best of two worlds you will probably have some TG's in the data file.

                       

                      We would never have any scripts in the data file EXCEPT for those few used for creating accounts across the soultion etc. etc.

                       

                      Best regards


                      Carsten

                      • 8. Re: Separation and Relationships
                        nickalex

                        Great points, Carsten, many thanks...I understand