3 Replies Latest reply on Apr 25, 2013 7:43 AM by ecshelp

    Strange Behavior

    gmint

      I've been reworking a portal for a solution which I have updated to FMP 12 because it previously relied on portal filtering which is now extremely slow (read unusable) even with a relatively small (i.e. in the low hundreds). However, in the process of doing so, I've encountered some strange behavior. Granted, it probably has to do more with the fact that I'm overlooking something, but I thought I would ask around nevertheless, so here it goes...

       

      What I'm trying to accomplish (and had working in FMP 11) was a search that works by narrowing down items in a portal as more characters are entered. It doesn't need to refresh after each character is entered, just when the user hits enter/return. So here's how I tried to set it up initially:

       

      I have a Global field called SalesItemFilter where the search is entered.

       

      I have another field called SalesItemMatchField which is a calculation as follows: Left ( ItemName ; Length ( SalesItemFilter ))

       

      Therefore, let's say I'm looking for an item (Budweiser) and I type "Bud" into the SalesItemFilter field, then I also get: "Bud" in the SalesItemMatchField which should (at least in my mind) give me a match which generates the results I want in the appropriate portal. But, it doesn't.

       

      So, I tried the same thing with a cartesian join for the relationship AND used the following as a portal filter:

       

      ItemQuickFind::SalesItemFilter = ItemQuickFind::SalesItemMatchField

       

      which also does not give me the correct results.

       

      HOWEVER, and here's the odd part (again, at least in my mind), if I eliminate the cartesian join and use the relationship from the first example AND use the portal filter, it works. That seems duplicitive to me and, to be quite honest, I don't understand why it works there but does not work in either of the previous examples. Also, I'm afraid that it could break somewhere down the line and since I don't understand how it works, I won't be in a very good position to fix it.

       

      Any insight would be greatly appreciated!

        • 1. Re: Strange Behavior
          comment

          I got a little lost in your description, but a couple of things are clear:

           

           

          1. A calculation referencing a global field, such as your example

           

          Left ( ItemName ; Length ( SalesItemFilter ) )

           

          must be unstored and therefore cannot be used as matchfield on the "other" side of a relationship.

           

           

          2. A portal filter based on the condition =

           

          ItemQuickFind::SalesItemFilter = ItemQuickFind::SalesItemMatchField

           

          should work - if the portal is set to show records from the ItemQuickFind TO.

           

           

          3. If you don't want to do portal filtering, you can use a custom function or a repeating calculation field to "explode" the item name, for example "Budweiser" will become =

           

          B

          Bu

          Bud

          Budw

          Budwe

          Budwei

          Budweis

          Budweise

          Budweiser

           

          This calculation can be stored and used as the matchfield opposite the global SalesItemFilter field.

          • 2. Re: Strange Behavior
            gmint

            Michael,

             

            I agree that my description of the issue is certainly lacking. Thank you for your answer. I suspected as much with the unstored calc. In all honesty, this is one area where I can just never quite remember exactly what the rule is with respect to relationships. In any case, I appreciate the alternate approach. As I indicated, how I have it setup now is working, but if I encounter problems, I'll definitely consider the approach you've laid out!

            • 3. Re: Strange Behavior
              ecshelp

              I believe I have a similar issue to you and it happened in FM12 (FM11 worked just fine).

               

              In my database, I have a layout named Hardware (to display Computer Hardware records). In this layout, I have a portal so can view the Software attached with certain hardware records.  When I go to add a Software record, it performs a script, which allows me to view all the Software records and once I find the record I need, I attach it to the Hardware record.  However, when I'm trying to use the Search field, it is INCREDIBLY slow when typing and sometimes forgets letters.  Below is the script we use to attach a software record to a hardware record:

               

              Allow User Abort [Off]

              Set Field [global::g_search; ""]

              Go to Layout ["Software" (license_software)]

              Show All Records

              Sort Records [Restore; No dialog]

              Go to Record/Request/Page [First]

              Adjust Window [Rezise to Fit]

              Go to Field [global::g_search]

              Pause/Resume Script [Indefinitely]

              Set variable [$SftwrID; Value:license_software::pk_software_id]

              Go to Layour ["SoftwareLicensing" (software_licensing)]

              New Record/Request

              Set Field [software_licensing::fk_hardware_id; MiddleWords(Get (ScriptParameter);1;1)]

              Set Field [software_licesning:fk_software_id; $SftwrID]

              Commit Records/Requests[]

              Perform Script ["GoToHardware"]

               

              While I know the work-around you have Michael is a good alternate approach, I'm open to other suggestions in order for us to have the Searching work like it did in FM11.