4 Replies Latest reply on Feb 27, 2013 8:51 AM by Matty_1

    Relationships outside of current Database



      Relationships outside of current Database


           Do relationships somehow differ when referring to databases outside of the current one you're working in?  (This is a first for me)  I currently have a calculation field constantly showing "Highway Tractor Equipment" with an equal relationship to a field labeled Category in another database as a value list.  When I click on the value list I see all records instead of only the records with a category marked as Highway Tractor Equipment.

        • 1. Re: Relationships outside of current Database

               By "outside the database" I am assuming you mean that you are linking to tables from another file.

               Tables linked via an external data source reference function just as though they were defined within the same table. Once upon a time, links to external files were the only way to related tables due to older versions of FileMaker being limited to one table for each file.

               You'll need to investigate your value list definition and the relationship match fields--their values and their data types, to see what is keeping this from working.

          • 2. Re: Relationships outside of current Database

                 The minute I read "investigate your value list definition" it clicked, oh shoot I bet I accidently forgot to select only show related records as of ..... 

                 Sure enough that was the problem.  Because I've never dealt with pulling data from another file I figured maybe things worked differently and didn't do too much digging.

                 From a general stand point, what are the performance/design advantages and disadvantages to have things sit in different files versus all under one roof?

                 Thanks Phil.

            • 3. Re: Relationships outside of current Database

                   There are trade offs for either approach. Multiple files complicate your solution and we often recommend that new developers keep it to a single file for that reason. Controlling access via a password is more complicated as you define accounts and passwords in each file. This usually requires defining identical account names and passwords in each file for each user--managing them becomes something best done with global fields and scripts.
                   Since variables only "live" in a given file, other means to move data from one table to another must be set up and you may no longer have a single central Relationship graph documenting all your relationships.

                   On the other hand, deploying updated copies of your solution are much simpler with individual files as you may only need to swap out a single file for a new one and then only import that file's data into the new copy.

                   Many developers use a compromise design approach called the Convert to Seperation Model. It splits a solution into two files: Interface and Data. The Interface file contains all scripts, layouts, value lists, etc and the Data file contains all the data tables. This approach allows you to deploy new copies of the interface file simply by replacing the old file with the new.

              • 4. Re: Relationships outside of current Database

                     Very cool, never thought of that.  This would allow me to test changes until my face turns blue and not disrupt the live database.  Thank you very much Phil :)