2 Replies Latest reply on Dec 27, 2012 11:21 AM by Dekade

    Little bit of "Edit Relationship" confusion

    Dekade

      Title

      Little bit of "Edit Relationship" confusion

      Post

      Layout 1: is my COMPOs Main which is the layout that I originally started to use to have each record represent a different document Composition (thus COMPOs).

      Layout 2: This is a layout that I created so that I could have a portal on it where I could check mark (X) one portal rows where each portal row represented a TOPIC that I wanted to be assigned to the COMPO ( composition ). Then I discovered that I wanted to see both the Composition and the check-box portal on the same layout. I soon discovered that this required another table occurrence of which I successfully created. I titled the Table Occurrence as "Checkboxes with COMPOs"

           Here is my problem. This entire database and it's relationships were not all my work. Now I am modifying things to fit the aesthetic feel that I desire. That being said there are MANY relationships and Table Occurrences associated with this whole project. I am concerned with the selection of check-boxes within the Edit Relationship window.

           I want to make certain that my creation and/or deletion of records does not affect other Relationships that would also have the same creation and/or deletion of records function enabled.

           Could someone help me out here? I think it might be kinda a can of worms but I had to start somewhere to learn how to handle this.

           If you need attachments to help me through this please tell me what is going to assist your determinations on how I should handle the relationship.

           Thanks,

           Dekade

           (FM Pro Advanced 10.0)

        • 1. Re: Little bit of "Edit Relationship" confusion
          philmodjunk

               There's really not enough detail to provide you with much help.

               "Allow creation..." is a check box that does not entail big risks for your data in any scenario that I can imagine. The worst you might get is an extra blank row in a portal where you don't want it--the bottom "add" row used to add new related records directly in the portal. You do want to be careful not to remove this optio in an existing relationship without carefull analysis and testing. This feature may be required for a data entry portal or it can be needed for certain scripts that use the relationship to create new related records.

               "Delete..." is the check box to select with great care. If "delete" is selected in an occurence of Table B relationship between table A and Table B. Deleting a Table A record anywhere in your database will invoke that delete setting and delete any related records in Table B. You can even get a "cascade" of deletes where deleting a record in one table deletes records in a second which then deltes records in a third...

               I suggest that you do what you can to organize your relationship graph to make it easy to see what occurrences refer to a common data source table. I try to color code mine so that all with the same source table are the same color. It can also be helpful to use a naming convention where the name of the data source table is part of the occurrence name, but in ALL CAPS to help identify the source table.

               Working towards an Anchor Buoy format can also be helpful.

               And FileMaker Advanced will be very helpful for you in being able to create a database design report. Not only can doing text searches on this report help you track down specific details such as every script that has a delete reocrds step, there are third party tools that can take a database design report and help you analyze the design.

               And as in any development endeavor, test your changes frequently and make lots and lots of backup copies when developing so that you can revert to an older copy if you find that a particular change didn't work out like you expected: Saving Sequential Back Ups During Development

          • 2. Re: Little bit of "Edit Relationship" confusion
            Dekade

                 Forgot to say thanks,

                 Have followed one of your designs very closely.

                 I just need to slow down and follow the accounting trail via many tests and many DB backups.

                 Dekade