1 2 3 Previous Next 105 Replies Latest reply on May 10, 2017 3:09 PM by RickWhitelaw

    10(0)1 FileMaker 'Gotchas'

    mrwatson-gbs

      Can we make a resource of a 101 FileMaker 'Gotchas'? 1001?

      Hello everybody, this is my welcome offer for the new FileMaker Developer Community!

      What's a 'Gotcha'?

      According to Wikipedea a Gotcha is:

       

      • a relaxed pronunciation of "I've got you", usually referring to an unexpected capture or discovery.
      • (programming): an unexpected or unintuitive, but documented, behavior in a computer system (as opposed to a bug)
      • a common colloquialism meaning to understand or comprehend.

       

      What's an FM-Gotcha?

       

      • A bit of FileMaker that doesn't work the way you'd expect it to (bug or no bug).
      • It's a bit like a gremlin: You want to get it* before it get's you**!

       

      * To "get it" you have to:

       

      • Do some Gotcha-busting, that is:
      • Understand the Gotcha-problem,
      • Possibly clean up some slime, and
      • Say "Ah! I gotcha!" (and with that the Gotcha dissolves into a ghost of the past, never to be gotten again)

       

      ** When a Gotcha gets you:

       

      • it sucks
        • sometimes real bad.

      The aim of this discussion

      • To create a repository of FileMaker Gotchas, a troubleshooter/Tsunami-warning system/suck-barometer of the FileMaker-unexpected.
      • To help the FileMaker Developer Community identify FM-Gotchas, do some Gotcha-busting and make FileMaker a safer place to develop.
      • To warn and be warned
      • To learn when to expect the unexpected
      • To understand FileMaker and be able to say 'I gotcha!'
      • To have a little fun.

       

      For now I'm just gonna start with one - ok two - of my favourite nasty little Gotchas (one gremlin and one bug). Please add more. The nastier the better ;-)

       

      Have fun, and happy Gotcha-busting!

       

      Russell Watson (MrWatson)

       

      P.S. Please Reply to this first entry to add a new Gotcha and feel free to sequentially number the Gotchas, so we can see when we get to our goal of 10(0)1, thank you!

      And reply to the individual Gotchas to discuss them.

       

      A Template for FileMaker Gotchas

       

      I thought I should give you a template you can use to make your own entries:

       

      FM-Gotcha #nnn: A succinct title that clarifies the nature of this gotcha

       

      The expected behaviour: Describes what you expect to happen.

       

      The unexpected behaviour (the slime): Describes what actually happens.

       

      The gotcha: Explains what's happening/why it went wrong/how FileMaker works.

       

      The suck: A short description of how much this gotcha sucks/the damage it can cause/the knock on effects it has.

       

      The bust: how to bust this gotcha, that is, how to avert it, best avoid it, patch it, or at worst how to minimise the damage it does.

       

      mrwatson-gbs added a Template for FileMaker Gotchas

        • 1. Re: 10(0)1 FileMaker 'Gotchas'
          mrwatson-gbs

          FM-Gotcha #1: My calculated field is being calculated from the wrong table occurence (TO) and not from the primary table occurence (PTO)!

           

          The expected behaviour: when you create a calculated field, you expect it to be calculated from (what you consider to be) the PTO (e.g. from "_Contacts")

           

          The unexpected behaviour: the field is being calculated from a different TO! (e.g. from "Contacts.MainContact")

           

          The gotcha: the first created table occurence of a table is the PTO (i.e. the calculation context, when you create a new calculation field). Naming a duplicate TO so that it looks like the PTO, or using the duplicate for Layouts/as the PTO doesn't make it the PTO!

           

          The suck: if you've been got by this Gotcha it can really suck. You have to:

           

          1. Change your relation graph & layouts & scripts & value lists so that the real PTO ("Contacts.MainContact") is the basis for calculations and Layouts, etc.
          2. or (if the effort of option 1 is too much) just live with it. But that just sucks even more, because the problem ain't gonna go away, and gets bigger and bigger.

           

          The bust: ALWAYS use the first TO as the PTO!

          • 2. Re: 10(0)1 FileMaker 'Gotchas'
            mrwatson-gbs

            FM-Gotcha #2: Copying and Pasting an "import records[matching fields]" script-step loses the matching fields option.

             

            The expected behaviour: copying & pasting anything should create an object identical to the original. The pasted script step should import all matching fields from the source table.

             

            The unexpected behaviour (the slime): after adding a field to source & destination tables and running the script again the new field is unexpectedly empty and seems not to have been imported - although it's name is identical in source and destination tables!

             

            The gotcha: The "matching fields" option of the import records script step has not been copied!

             

            The suck: if you've been gotten by this Gotcha it can really suck, because it only first causes problems after you have added a new field. By then you may have released your database to 10(0)1 customers.

             

            The bust: Either:

             

            • If possible, use duplicate or import scripts to duplicate the script/script step - this works.
            • or: ALWAYS edit the script step after pasting to reapply the "matching fields" option.
            • 3. Re: 10(0)1 FileMaker 'Gotchas'
              BenoitJolly

              I may have misunderstood, but why wouldn't you use the "Evaluate this calculation from the context of" option at the top of your calculation box ?

              • 4. Re: 10(0)1 FileMaker 'Gotchas'
                mdiehr

                Related Gotcha 2B:  in some cases, adding or deleting a field to a table causes some Import Script steps with custom field-matching orders to get confused, even if the field that you added (or deleted) was not one of the fields being used in the import.   Since filemaker internally refers to fields by ID (rather than name, or order in the table), this is unexpected and a subtle and nasty gotcha.

                 

                Painful Workaround: after adding or removing a field, check ALL import scripts that reference that table to make sure this has not happened, and manually re-edit the field matching to fix it.

                 

                Regression:  This doesn't always occur, and I think it's less likely to occur if you create a field at the end of a table, rather than creating a field and then dragging it higher in the table/field order?

                • 5. Re: 10(0)1 FileMaker 'Gotchas'
                  dhrowe

                  Or I think the Related Gotcha for 2 might be NEVER delete a field.  Create new ones.  If don't need one any more then put 'zz ' or something at the beginning of the field and it will sort at the bottom.  Possible make it a global so it does not take up space with data.  Then later if you need a field, use one of your 'zz' fields.

                   

                  a. Solves most of the import export issues, because you are adding and deleting fields.

                  b. IF you ever have to rebuild the table.  It is possible since you could then just show by creation order, and recreate those fields. 

                   

                  I wish I had figured this one out years ago.

                  • 6. Re: 10(0)1 FileMaker 'Gotchas'
                    mdiehr

                    I'm sure you are correct that deleting fields can trigger this issue, but I'm 99% sure I've seen this bug when creating a new field.    (Most of my work has been in FM 9v3, not sure if I've seen this in FM11 yet).

                     

                    FYI, I always look at my table fields using "Custom Order" sorting, so adding "zz" wouldn't help for the way I use filemaker...

                    • 7. Re: 10(0)1 FileMaker 'Gotchas'

                      Michael,

                       

                      The creation order is the order of ascending IDs. It does not matter in what order you show your lists (except for the relation graph).

                       

                      If you delete a field that has a higher ID than those of the fields to export or import, no problem will occur.

                      In any other case the place of the deleted field will be used by the field with the next higher ID, hence the wrong fields will be used, which in fact is a drain.

                       

                      New fields will be added to the export order regardless.

                       

                      If I don't need a field anymore I rename it to "•••oldName" and change it to global storage, so it doesn't need much space anymore. This way export and import orders stay as they are.

                       

                      Winfried

                      • 8. Re: 10(0)1 FileMaker 'Gotchas'
                        mrwatson-gbs

                        You can.

                         

                        And, in fact, you must, if you've gotten into this little trap.

                         

                        The problem is, that you just don't do it. At least not until you've noticed the problem, and by that time you've already built n calculation fields wrong and screwed up your customers book-keeping.

                         

                        I've got a niggling feeling that this isn't just a loss-of-comfort-thing, but there is a situation where things just don't work, because the PTO's wrong.

                         

                        Anybody got any tips?

                        • 9. Re: 10(0)1 FileMaker 'Gotchas'
                          mrwatson-gbs

                          FM-Gotcha #3: Deleting a field is just not the same as deleting a script

                           

                          The expected behaviour: When you delete a script, FileMaker happily continues to reference and call all of the other scripts correctly. You would expect the same to be true of deleting a field: that all other fields continue to do what - and moreover go where - they should.

                           

                          The unexpected behaviour (the slime): After deleting a (quite old) field from table A, every "import records" script step where you import Table A into another table will possibly be broken. All of the newer fields have shifted up a place and are importing into completely the wrong fields.

                           

                          The gotcha: The field order in an import records script step is NOT based on ids, but on the sequence of the fields in the source table. Delete the third field of the source table and the fourth field becomes the new third field, the 4th the 3rd, and so on.

                           

                          Look, here is what is placed on the clipboard, when you copy an import records script step:

                           

                          <?xml version="1.0"?>
                          <fmxmlsnippet type="FMObjectList">
                                    <Step enable="True" id="35" name="Import records">
                                              <NoInteract state="True"/>
                                              <NotWinStep state="False"/>
                                              <Restore state="True"/>
                                              <DataSourceType value="File"/>
                                              <Profile table="1065089" FirstRowIsData="False" DataType="FMPR"/>
                                              <UniversalPathList>$path</UniversalPathList>
                                              <ImportOptions CharacterSet="Unicode" AutoEnter="True" SplitRepetitions="True" method="Add"/>
                                              <Table id="13631889" name="_DummyDaten"/>
                                              <TargetFields>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="Import" id="43" name="Name Text"/>
                                                        <Field map="Import" id="42" name="Name ID"/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="32929" name="User"/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                                        <Field map="DoNotImport" id="32978" name="zzz dont delete me"/>
                                                        <Field map="DoNotImport" id="32979" name="zzz dont delete me either"/>
                                                        <Field map="DoNotImport" id="0" name=""/>
                                              </TargetFields>
                                    </Step>
                          </fmxmlsnippet>
                          

                           

                          You see, only the Target fields are specified. The source fields are just sequentially mapped to the Target fields. This example only imports the 3rd and 4th source field into the Name Text and Name ID fields.

                           

                          The suck: This Gotcha can REALLY mash-up your data.

                           

                          The bust: Either NEVER delete a field OR be prepared to check every import every time, or to spend hours sorting out screwy data.

                           

                          Thank you mdiehr for the great Gotcha(s), because I think what you mentioned are two separate cases...

                          • 10. Re: 10(0)1 FileMaker 'Gotchas'
                            mdiehr

                            Winfried, thank you for the explanation.  I still think that this is a bug -- for most other situations, FileMaker is very good about referring to objects by an internal ID rahter than order or name.  (This is why you can rename and delete fields, tables, TOs, without issue).  Either filemaker does the right thing by warning you "Field X is used in calculation Y, are you sure you want to delete"?  or in some cases it just displays "field missing".     It's one of the pleasures of working with FM as opposed to other DBMS.

                             

                             

                            However with Import scripts, the behavior is totally different and unexpected, it neither warns you that the problem is going to happen, nor does it minimize the damage...

                             

                            Update: mrwatson-gbs says it better

                            • 11. Re: 10(0)1 FileMaker 'Gotchas'
                              mdiehr

                              FM-Gotcha #4 : Relationships between Text and Number fields work fine, until they don't.

                               

                              Most of the time you can ignore the field type of a relationship : Matching between a Text field (containing integers) and a Number field (containing integers) works. 

                               

                              FM is quite flexible: you can include numbers in text fields (of course) and you can also include text in number fields (which is not obvious).

                               

                              However, in some cases these matches don't work, and this often takes a while to debug.   I think one example is a number field with leading zeros.

                               

                              It would be nice if FM could warn you of these cases when you create an offending relationship, (and/or let you search for them after the fact...)

                              • 12. Re: 10(0)1 FileMaker 'Gotchas'
                                mrwatson-gbs

                                FM-Gotcha #5: Adding a field is just not the same as adding a script

                                 

                                The expected behaviour: So I added a field to the table, what's the big deal? It's just a field. - Isn't it?

                                 

                                The unexpected behaviour (the slime): The unexpected deal, is that the contents of your new field are suddenly appearing in strange places, seemingly randomly in your database. What is going on? Is some user messing around? Is there a script trigger somewhere? Is the file damaged? Is a script replacing the contents of the wrong field somewhere? Where then? What does the DDR say? Answers: Don't know, probably, not that I can find, doesn't seem to be, maybe, er..nope. 2 to 6 hours later: Hm, none of the above.

                                 

                                The gotcha: FileMaker thought it would be a good idea to add all new fields to the end of import scripts steps AND TURN THEM ON, so that they automatically are imported.

                                 

                                Not great. Not good. Not even average. Argueably a poor show.

                                 

                                So long as you only import big tables into little tables it doesn't really matter.  (Clarification: I mean wide and narrow, i.e. lots of fields into a table with few fields)

                                 

                                - But - everywhere you import a little table (n few fields) into a big table (m many fields), there's a Gotcha lurking, waiting to suck your patience and comprehension out of your soul and brain. Add a new field and -pow- it gets imported into field n+1 somewhere.

                                 

                                The suck: It sucks like random chaos, but is not so beautiful. It can take a time til you discover the cause.

                                 

                                The bust: Either: NEVER add a field to a database, OR use FileMaker-to-FileMaker imports sparingly OR know where the problem imports lie and DOCUMENT them.

                                 

                                Thanks again mdiehr for inspiring these great Gotcha(s),

                                • 13. Re: 10(0)1 FileMaker 'Gotchas'
                                  mrwatson-gbs

                                  warn and be warned...that's what we're doing.

                                   

                                  FM has facilitated the warning, by providing us with this website.

                                   

                                  ty FMI!

                                  • 14. Re: 10(0)1 FileMaker 'Gotchas'

                                    Russel,

                                     

                                    Expectation varies heavily among people. Some say it's unexpected behavior, others call it a bug.

                                     

                                    If you take into consideration that the export/import routines still walk around in clothes they got more than 20 years ago, you may conclude: it's no surprise. These routines definitely need a modern counterpart that avoids all the hassle the old ones cause.

                                     

                                    How about Read, Write, and Push (that pushes data into another file instead doing an import from the other side)? These (menu and script) commands must provide a fixed matching table where BOTH sides are identified by their ID.

                                     

                                    Meanwhile the only thing you can do is to constantly knock on FMI's door and ask for exactly that.

                                     

                                     

                                    Winfried

                                    1 2 3 Previous Next