3 Replies Latest reply on Nov 14, 2011 6:53 PM by disabled_winfried

    Legacy fields behaving badly

    mardikennedy

      This is just for the record... I have one particular, occasional client who has a solution originally designed (3 developers back) in pre-7, and since partially optimised. Given that it's a manufacturing company with complex needs, it would come as no surprise that the solution is... labyrinthine. Oh well, a curious discipline of sorts.

       

      The discovery: I had to do a new report recently and I copied an existing report as a starter. Added some field defs with formulae and repointed fields on the report to the new defs. Also created fresh copies of the fields back on the form layout so that I could click through records to check how they were performing. Frustration - poor results. Suddenly I realised that the fields were displaying different results for the same record on each layout. Huh? Must be a clumsy, tired eyes kind of developer error, yes? eg different TOs, etc etc?

       

      Actually, no. It was truly weird. Eventually I set up two copies of exactly the same field - the original 'repurposed' one and a fresh one - on the report layout, and they displayed different results. I have never seen anything like it. I can only hypothesise that the 'old' one - in this oft reworked file - somehow clung on to an erroneous index or something. I don't know if being on a List layout had anything to do with it. Naturally, it was easy to make the 'bad' one disappear forever.

       

      The lesson to take away: usually if there's a really wacky result, it'll be a developer error. But just very occasionally, if your gut tells you that your calc is correct, it's worth digging a little deeper and checking for the highly unlikely possibility.

       

      Regards,

      Mardi Kennedy

       

      Note: With no urgency, I'm open to suggestions of an off-the-shelf, customisable package that might better serve them into the future. They're not planning on this right now, but I'm willing to start pitching something that's a few generations beyond what they have, as it's getting increasingly hard to support old architecture (even tho' it's study and fundamentally well-designed). It'd probably end up being a 6 to 12 month decision cycle - quotes, jobs, production tasks and time, materials, contacts, invoicing and reporting/ planning.

        • 1. Re: Legacy fields behaving badly
          RayCologon

          Hi Mardi,

           

          FWIW, I've recently had two different clients report remarkably similar experiences to the ones you reported - complex systems, copied-and-updated calculation returning one result, re-created but "otherwise identical" new calc field giving a different result. However in each case I was able to pinpoint the cause and found it to be not so mysterious.

           

          In one case, the issue turned out to be that the calc field that had been copied and modifed brought with it an "Evaluate this calculation from the context of:" setting that pointed to a TO that was not the default TO for the table, and caused the context to return slightly different sets of related data. The newly created calc, however had reverted to the first-created TO for the table, and didn't exhibit the same behavior. The developer who had made the changes and been puzzled by the results was not accustomed to checking on context for calculations in schema, but evidently one of their predecessors had made use of this feature.

           

          The other case turned out to be to do with the fact that there were two very similarly named fields (with quite long names, only one or two characters different) in two very similarly named TOs (also quite long names). While the two calcs that were behaving differently were very similarly defined, it turned out that one of the field references was actually to a different field - though very difficult to spot because of the naming convention that had been applied.

           

          I'm not meaning to suggest that either of these was the specific cause in your case. But in my experience, corruption is rarely responsible for behavior of the kind you've described - usually there's a more mundane cause. However, to set your mind at rest, you might like to see if a recovered copy of the file (eg one with all the indices rebuilt) exhibits the same problem. If it does, then it would be reasonable to conclude that a flakey index was not the cause.

           

          Cheers,

          Ray

          ------------------------------------------------

          R J Cologon, Ph.D.

          FileMaker Certified Developer

          Author, FileMaker Pro 10 Bible

          NightWing Enterprises, Melbourne, Australia

          http://www.nightwingenterprises.com

          ------------------------------------------------

          • 2. Re: Legacy fields behaving badly
            mardikennedy

            Hi Ray,

             

            Agreed - tired eyes and/or other developer error (in my case!) is much, much more likely to be the cause.  That said, I spent an embarrassing amount of time checking those field names, TOs and context because all of those items seemed much more likely to be the issue.  Even still, maybe I missed something?

             

            It was only after that, that I resorted to the Profoundly Illogical option.  ;-)

             

            In an ideal world, I would have more of a poke around in a backup copy but this isn't going to happen for various reasons - I don't have (easy) access to their backup files and I rarely physically visit that site; I also don't have the extra time for this.  (Yes, I was working directly on the live, served files, though out of conventional hours, but the bits I was adding were reasonably 'tiddly', relative to thesystem as a whole.)

             

            Thus, expediency was a motivator but I was relieved that I was able to resolve the problem without further time wasting!  That said, it would be good to further explore but sadly, it ain't going to happen just now.

             

            Cheers,

            Mardi Kennedy

            • 3. Re: Legacy fields behaving badly

              Mardi,

               

              It's good to (and one should always) have a copy of the old solution before making changes to the current version. And if there was anything different FMDiff would show it. Unfortunately you did not show the calculation that gave the wrong results, so one could make an assumption on what may cause this.

               

              If it was caused by one of the cases Ray had mentioned I'm glad you could resolve it.

              But since you were blaming it on the legacy field (what legacy exactly?) I'd like to mention:

               

              - If there should have been a problem with the .fp5 calculation, it could not be converted to .fp7 without either correcting it or ignoring it (/* commenting it out /). So your .fp7 files are very likely OK on the beginning. The same is true for copying and pasting (and importing calculations and scripts) within .fp7 files, but when referenced items are missing they are either <missing> or / commented out */.

               

              - There are always two versions of a calculation stored. One consists of the text exactly as entered and the other (i call it byte code) that has replaced table and field names with their respective IDs, removed comments and white space, as well as prepared other values to be better digested by the calculation engine. In a damaged file you may see your calculation as entered while your byte code might be missing or corrupted, or the other way around.

               

               

              Winfried