9 Replies Latest reply on Aug 10, 2009 1:18 PM by philmodjunk

    Constraining Portal Results



      Constraining Portal Results


      I have a portal that is showing daily jobs.

      I would like to have the same portal only show jobs for a particular sales person.


      I created a relationship that takes the jobs per day (job ticket) and relates it to a copy of itself called By Sales.

      job ticket salesman = by sales "justin"


      This of course is not working or I would not be writing this :)


      Any help?!

        • 1. Re: Constraining Portal Results

          What does your current portal relationship look like?


          TO::date = TO2::date


          or some such?


          If so, create a new relationship to a new table occurrence (TO) and add one more pair of fields to match them by SalesPerson ID (best) or name (second best). Using the above example, you'd get something like this:


          TO::date = TO3::date AND TO::SalesPersID = TO3::SalesPersID


          This will give you all jobs for the same day AND the same sales persion.


          Is that what you want?

          • 2. Re: Constraining Portal Results

            My relationships are as followed


            Currently I have 


            TO (Sales Daily): Ship Date = TO (Jobs_Packing Slips): Ship Date


            This brings up all the jobs per that day.


            My "salesperson" field is in the packing slips database, not in the sales daily database at all.

            The person that i'm searching for is under a field called "salesperson_justin"


            This is tricky because my packing slips db is related to a customers db that contains the salesperson field by customer.  

            • 3. Re: Constraining Portal Results

              From your original language I thought you were describing a Self Join (both sides of relationship refer to same basic table.)


              If I undestand correctly, you need:


              Sales Daily:: Ship Date = Jobs_Packing Slips::Ship Date AND Sales Daily::salespersion_justin = Jobs_Packing Slips::SalesPerson


              I'm assuming that "Salesperson_justin" is part of the Sales Daily table and is of the same data type as Jobs_Packing Slips::Salesperson


              BTW, this is called a "filtered portal" and there are several other threads here that describe this technique. You might want to use the Advanced search link above to check them out.

              • 4. Re: Constraining Portal Results

                Salesperson is only in the packing slips field.


                The Sales Daily TO refers to calander dates (and that's all it does)


                Packing Slips refers to all of my jobs.


                So...sales daily:shipdate = packing slip:shipdate in which the ship date on sales daily refers to a calendar date and the ship date on the packing slip draws in the jobs that shipped on that specific calendar date.


                All of my job information is in the packing slips (this includes the salesperson field)


                So i have nothing in the sales daily db to tie the salesperon field to. Do i need to make something?


                • 5. Re: Constraining Portal Results

                  "So i have nothing in the sales daily db to tie the salesperon field to. Do i need to make something?"



                  Try this:


                  Define a global field for your salesperson in the sales daily table.

                  Use it in the above relationship (I'm still assuming you want both same day and matching salesperson info)

                  Place this field above/near a portal based on the new relationship.

                  Format the new global field with a value list that lists salespersonnel.


                  By selecting different personnel from the value list, you should get different sets of matching records in the portal.

                  • 6. Re: Constraining Portal Results

                    it will not let me reference my salesperson_justin field because as I said before that field is actually drawing from a seperate table called Customers. We can enter who the salesperson is on each customer record.


                    Salesperon is origionated in Customers....then i needed to pull it into the packing slips (this is done by an auto enter calc)....now I need it in the Sales Daily db.



                    I can try to change some things around if you wouldn't mind helping me out. Most of this was done before I started with it, so i'm trying to clean up what was previously done.



                    Origionally salesperon was only a text field in which initals were entered into. I had to leave that as it was so that the origional fields would still be in tack, but i made relating fields to our 5 different sales people that took that field and related the different sales people to numbers.


                    I just can not get this into the sales daily db, nothing will work :(

                    • 7. Re: Constraining Portal Results

                      I've ignored the salesperson_justin field for that reason.


                      I've described adding a new, blank global field to your Sales table instead.


                      In the example I've described, you will have an empty portal until you select a value for the global field that matches to records in the packing slips table of the same date.


                      Will this work for you?

                      • 8. Re: Constraining Portal Results

                        I've done what you said and when i get to the last step making it a value list to drop down the sales people, it will not let me because that salesperson field is comign from a unrelated db and it's pulling it via calculation.

                        Filemaker will not let me make the global field a value list based on our salespeople.

                        • 9. Re: Constraining Portal Results
                             You can define a value list to list values from any indexed field in any table in your system. No relationship is required. Can you set it to refer to the original source rather than the (I assume) unstored calculation field?