2 Replies Latest reply on Jun 11, 2013 10:51 AM by davidrcrowe

    Multi-criteria Find with PHP API

    davidrcrowe

      I am trying to do a multi-criteria find with the PHP API, i.e. have an HTML <textarea> element with, say, a list of cities, one per line. But I am getting "no records found" on every attempt. Is there a delimiter character that allows this, as you can do with scripting? I've tried ASCII 10 and 13. If it doesn't work, I have alternatives, but they are a lot more work.

        • 1. Re: Multi-criteria Find with PHP API
          mbraendle

          We could help better if you showed the PHP code in question.

           

          I assume you want to do a Boolean OR search.

           

          One way is to split the value in the textarea to individual cities, use the newCompoundFindCommand and for each city add a newFindRequestCommand  and an addFindCriterion.

          • 2. Re: Multi-criteria Find with PHP API
            davidrcrowe

            It's not really the PHP code that's the question.

             

            I have an HTML textarea with postal codes. The user enters the postal codes, but for illustration, let's say it's equivalent to this static HTML:

             

            <textarea>

            H0H 0H0

            A1B 2C3

            D4E 5G6

            </textarea>

             

            When I get this code the lines are separated by ASCII character 10. I believe that FileMaker uses ASCII 13 as a line separator. But even substituting 13 for 10 doesn't result in any records being retrieved (even though I'm using values that work individually, if only a single line is specified).

             

            The first question is whether the FileMaker PHP API supports multi-key searches (as it does via a FileMaker client). And, if so, what character it  expects to delimit the individual keys on separate lines.

             

            The reason to NOT use compound finds (I am already using them for different purposes) is that if I end up with multiple fields like this the size and complexity of the find command will explode. I'd rather do it like this, but if I can't I'll bit the bullet.