6 Replies Latest reply on Apr 30, 2014 11:08 AM by trm1945

    Addresses, portals and sorting.


      Is there some convention on sorting addresses by their street number content? For example does # 3, 320 Cherry Lane come before or after 333 Main Street or Apt 330, 1120 Second Ave? I'd like to assume a sort on the field's street number only content meaning some way of telling street numbers from house and apartment numbers. The purpose of this sorting is to quickly identify an address by the street number with apartment etc. numbers as secondary information. In the example here, the sort would be: 320 Cherry Lane, 333 Main Street, 1120 Second Avenue. I can see the spaces and lack of them in these addresses but an elegant solution is just beyond me. Also, initial data entry in separate fields may be too much to ask. I really don't care how complicated a solution is as long as that complexity stays inside the program.

        • 1. Re: Addresses, portals and sorting.

          Is there some convention on sorting addresses by their street number content?


          Text fields sort by text, so you’ll see this sort of thing.











          You can have fields for each component of an address. Then you can sort by number, street, city and put the pieces back together in whatever shape they like. You just have to have a need that warrants the fussy data entry requirements.



          • 2. Re: Addresses, portals and sorting.

            +1 if you need this, your entry must be this.


            There are a few old ways of parsing this kind of data, if perhaps you import it already merged as a block of text. Lynne Bradford had one (may she RIP) that was fabulous and behaved the way ACT could parse contact information. I'll see if I can find something.


            Apologies, I've just found Lynne's file and it was for NAME only parsing. This meant a single field with Honorific, First, Middle, Last (including multi-word lastname) and Suffixes could be easily placed into the correct fields. On the other hand, this same logic could apply to parsing an address field, I suppose. I like the way she did the parsing.


            -- sent from my iPhone4 --

            Beverly Voth



            Message was edited by: Beverly Voth

            • 3. Re: Addresses, portals and sorting.



              Any chance you could post Lynne's work, or a link to it?  That seems like an excellent tool to keep in one's tool belt.




              • 4. Re: Addresses, portals and sorting.

                I think I have that on an older system. It accounts for "de" and "von" and den" and "DDS" and "III" etc. as well as the most convoluted names imaginable. I also plan to parse names but I think it's equally important to include a Name field that gives the proper pronounciation, especially for foreign names.

                • 5. Re: Addresses, portals and sorting.


                  I've run into this and went the long way around; if the number is less than ##, then do this. If Length ## is 2 or 3 or 4 etc. but it would be easier if FileMaker had a "Numerical Text Value" statement that figures out that 120 is more than 13. (etc. etc. etc)

                  • 6. Re: Addresses, portals and sorting.

                    I've lost the calculations reply. I don't know where it went but it's disappeared. Can you re post it please?