6 Replies Latest reply on Dec 13, 2013 8:51 AM by mperley

    Identifying Used Fields


      Is there a way to determine which fields in a table are used in a solution, either on a layout or a calculation?


      Background: Our office uses FileMaker to extend the features of our sales and accounting software. We've traditionally just deleted all records and re-imported tables periodically throughout the day, but we're starting to see decreasing performance in those imports. Instead of importing every field from those tables, we're hoping to restrict the import to only those expressly required. However, since most of this was originally set up some time ago there is so simple way to know what fields are being used and which ones are not.

        • 1. Re: Identifying Used Fields

          No easy way that I know of. If it is a matter of just knowing which fields are on a layout, you could just go into layout mode and write down the fields. A better way would be to run a DDR report on your solution. DDR is a report that is available if you have FileMaker Pro Advanced. This report can show you all the fields on layouts, what fields are referenced by calculations, etc.


          If you want to take this to the next level, there are two 3rd party applications that can read in DDR data and give you a more complete picture of your database. They are BaseElements and Inspector. You can find both pretty easy by doing a search on the internet.



          1 of 1 people found this helpful
          • 2. Re: Identifying Used Fields

            Yes, DDR is great! There are also functions called "Design" functions.


            FM12: <http://www.filemaker.com/12help/html/func_ref1.31.31.html>

            FM13: <https://fmhelp.filemaker.com/docs/13/en/fmp13_functions_ref.pdf>


            These can be used to get quite a bit of information on layouts, tables, etc. They are calculations, so may be placed in fields, variables, scripted or otherwise. These may or may not be sufficient for your needs, but you may want to check them out!



            • FieldNames(fileName;layoutName) // Returns a list of the names of all fields on layoutName, in fileName file, separated by carriage returns.


            You can supply the fileName (in quotes) or use the function Get ( FileName ). The same with the layout. If you are running the value ON the layout queried, use Get ( LayoutName ) or the name of the layout needed (in quotes).




            1 of 1 people found this helpful
            • 3. Re: Identifying Used Fields

              Thanks, Beverly and Doug, this gives me a lot to work with. I'll start with the DDR and design functions, and then if needed move on to the commercial options.



              • 4. Re: Identifying Used Fields

                This may be a bit simple,  if you look at the table in table view, show all records and the field is empty,  it's a fair bet that it's not being used.


                This is a bit destructive, if you try to delete the field and it is used in a script or a calculation FileMaker will warn you about this.  It also opens you up to many oops type issues,  so if you do this be very careful.



                • 5. Re: Identifying Used Fields

                  Hi Mperley,


                  Whe I first saw your post and your comment about the imports getting slower, I wondered if you were in fact deleting all records and the slownes was due to the bigger indexing task accompanying each import. That''s a well known symptom with large imports.


                  If you get Base Elements to analyse your DDR it will indicate unreferenced fields. The same info is in the DDR if you know where to look.


                  Finally, be warned about losing your import mapping when you delete filelds in the recipient table. You'll need to get screen shots of every import map so that you can rebuild them after field deletion.


                  I hope that helps,



                  • 6. Re: Identifying Used Fields

                    John, thanks for the insight. We had been deleting all records and and then re-importing everything, and based on your comment about indexing I'd bet that was a big part of our problem.


                    Yesterday I spent some time and created a test copy of the solution and instead of deleting and re-importing every record I changed the import record task to "update existing records". This cut the import time from 23 minutes down to 6, so that is a great step in the right direction. Preventing the import of unreferenced fields will hopefully decrease the import time even further.


                    Thanks again for everyone's help.