14 Replies Latest reply on Apr 14, 2015 5:02 AM by c0nsilience

    Solution needed - batch field to table associations

    c0nsilience

      Hello all,

       

      Maybe one of you gurus can help me out with this.  Let's say I've inherited a database that has pretty good layouts and field types, so I want to keep those, but the previous developer created a lot of unnecessary and redundant table schema, so I'm going to do away with some of those and merge the rest into a single table. 

       

      For agile development purposes, is there a way to batch associate fields with a new table, without having to use the field picker and re-drag them/resize/re lay them out on a layout?  So that way, if I want to use existing fields and I'm staring at a layout that has 50 "missing table" designations, I can select all of the fields and re-associate them with their new table in one fell swoop?

       

      If this doesn't exist, why not?  I could certainly see where it could come in tremendously handy for a designer that is re-working layouts, or in the above-mentioned example.

       

      If any of you know how to do this, or if it's possible, please share it with the community.  I've looked long and hard for an answer to this question and have yielded nothing thus far.

       

      Thanks!

        • 1. Re: Solution needed - batch field to table associations
          BruceHerbach

          You might be able to use FMbutler:

          Try the following:

           

          1)Using FMbutler,  export the layout (before deleting the Table Occurrence( TO ) The fields must point to valid fields.

          2) Delete the old table occurrence and the old layout.

          3) Rename the TO that you want to use so that it matches the old name.

          4) Create a new blank layout based on the New TO with the old name and have FMButler import the exported layout.

          5) Rename the TO to the new desired Name.

           

          If the fields are based on the same table,  then the new layout should be based on the new TO and the fields should be valid.

           

          One drawback to all this is that it probably just broke your system navigation scripts.  This happened when you deleted the layout.  Other scripts that were based on the original layout may also be broken.  You need to check this carefully.  Depending on scripts,  it may be better to tie the layout to the new TO and then update the fields so that they point to the correct field.

           

          If you have already deleted the TO and the fields are broken.  Then you have no choice but to re-point them to the correct TO::Field.  You can do this by double clicking on a field and selecting the correct table occurrence and field.  You don't have to delete it and drag a new one from the field picker.

           

           

          HTH

          • 2. Re: Solution needed - batch field to table associations

            If it ain't broke, don't fixit.

             

            If you break it, you gotta fix it.

             

            What you are going to do is break a lot of things.

            • 3. Re: Solution needed - batch field to table associations
              Benjamin Fehr

              much things have changed with new FMP versions.

              Rebuilding all TO's according to Anchor-Boy principal is worth to do if the database is up to grow and maybe shell work on iOS-Devices in the future.

               

              Several working structures I can recommend:

              - make Backups before start and with every major work step. have the folders labeled with a timestamp.

              - change names of TO's in old solution according to some self-explaining naming-conventions before start the big overhaul.

              - use iCal to protocol major steps to get overview if any Bup-Retrives are needed. (You'll find entries on my Mac like "last Bup B4 Yosemite beta xy)

              - make save-as-PDF from current Relationship-Graph

              - Consider to work on 2 FMP versions at same time (FMP12 AND FMP13 for example) in order to have old and new solution opened at same time and also get surprised how much 'copy-paste' works between the two solutions.

              • 4. Re: Solution needed - batch field to table associations
                nicolai
                For agile development purposes, is there a way to batch associate fields with a new table

                 

                The issue you are experiencing has nothing to do with agile development process. I am not sure how you are applying agile to FIleMaker development, but it has nothing to do with functionality of the software/development environment.

                • 5. Re: Solution needed - batch field to table associations
                  Mike_Mitchell

                  "...the previous developer created a lot of unnecessary and redundant table schema..."

                   

                  This line in your original proposal jumps out. Can you elaborate? Because this line:

                   

                  "...I'm going to do away with some of those and merge the rest into a single table."

                   

                  is a data modeling red flag. Are you certain the original structure is "unnecessary and redundant"?

                   

                  Realize that often, table structures are split out for a reason. Sometimes, it's because the data model needs it. Sometimes, it's for performance. It's not at all unusual to use a one-to-one relationship between two tables so that often-changed fields are in one table and seldom-changed fields in another for caching efficiency.

                   

                  I don't know that this is the case here, but it might be worth backing up and asking the question. Before you go to all the work to refactor the solution.

                  • 6. Re: Solution needed - batch field to table associations
                    wimdecorte

                    nicolai wrote:

                     

                    For agile development purposes, is there a way to batch associate fields with a new table

                     

                    The issue you are experiencing has nothing to do with agile development process.

                     

                    +1 on this.

                     

                    Can you elaborate on your thinking here?  Because it may be a red flag in your overall approach.  Agile development cycles have nothing to do with architecture.

                    • 7. Re: Solution needed - batch field to table associations
                      Devon Braun

                      The idea of being able to select a bunch of layout fields at once and associate them to table fields with a more efficient interface than what FMP currently affords -- that's an interesting feature request.  Linking a lot of layout fields can be cumbersome with the current feature can be sluggish.

                       

                      One possible workaround:

                      If you're creating a new and improved database based on an old and less-than-optimal one, you can use the following technique:

                      When table::field names on your old database precisely match those of the new one you can use copy and paste.  Copy fields from a layout of the old database, paste them in the new one, and they'll link properly, no field picker necessary.  Styling is carried as well.

                       

                      If you're modifying an inherited database, consider copying it, and temporarily modifying names of that copy to take advantage of this feature.  Hope that's helpful.

                      • 8. Re: Solution needed - batch field to table associations
                        c0nsilience

                        You're absolutely right.  I mis-spoke when I used 'agile' to describe what I'm after.  What I meant to say was 'fast'.

                         

                        databoom, you hit the nail on the head.

                         

                        For all the other devs, many thanks for all of the advice and I'm sorry this thread has grown a little cold.

                         

                        Although it wouldn't be necessary all of the time, I think it would be ideal to batch associate fields with a particular layout if that tables change, merge, etc.  FM already has the mechanism to do this in the form of the Field Picker.....but it's sluggish at best if you're looking at a layout that has, say, 80 fields, on it. 

                         

                        What I'm after is a way to keep the layout design the same (it isn't fun to place and resize a few fields at a time on a slide control) and just point the elements to a different table.  I can see how this might be problematic and confusing, but I can also see how it would really, really speed up development and would be really helpful if you inherit a solution that had attributes broken out into several tables that were unnecessary, cluttering the RG to the point that it looks like spaghetti.

                         

                        Haven't you guys run across this before?  I've only been developing for 2-3 years now and I've seen it several times.

                         

                        Anywho, thanks for all of the great insight and datebook, yeah I think this would be a really interesting feature to have available.

                        • 9. Re: Solution needed - batch field to table associations
                          Mike_Mitchell

                          FWIW, the "spaghetti" problem on the Graph is well-known. Here's a DevCon presentation by Ray Cologon addressing some methods for organizing the Graph to prevent it from becoming quite the nightmare.

                           

                          DES002 - Taming The Graph - Techniques for Graph Modelling

                          • 10. Re: Solution needed - batch field to table associations
                            Devon Braun

                            Mike_Mitchell, curious to view that link, but access is restricted

                            • 11. Re: Solution needed - batch field to table associations
                              c0nsilience

                              Yeah Mike, I'd absolutely love to take a look at it as well and thanks for sharing it!

                              • 12. Re: Solution needed - batch field to table associations
                                Devon Braun

                                c0nsilience, glad that worked out. 

                                • 13. Re: Solution needed - batch field to table associations
                                  Mike_Mitchell

                                  Apologies. Here's a link to his original white paper. You should be able to get to this.

                                   

                                  Approaches to Graph Modeling (Last Updated: May 23, 2008)

                                  • 14. Re: Solution needed - batch field to table associations
                                    c0nsilience

                                    Thanks Mike!

                                     

                                    databoom, it really does make sense.