3 Replies Latest reply on Nov 4, 2009 2:59 PM by philmodjunk

    Filtered related table



      Filtered related table


      I have table of projects and the fields  are "types" and "titles". I want to create a related table that only shows records of a specific type. The specified type is not dynamic, so the value can be hardcoded into a script... so.. how do i do this?

        • 1. Re: Filtered related table

          No script needed, just a field with the right value. If you want, you can make the field a calculation to "hard code" it to one specific filter setting.


          Let's say you want all related records for the current customer but only if the value in a text field in the related table holds the text "red".


          Two tables: Customer, and Widgets


          Define a text field, RedKey,  in Customer that holds the text "red". It can be a text calculation that returns this literal text or an auto-entered value.


          Define your relationship to include the color fields in both tables:


          Customer::CustomerID = Widgets::CustomerID AND

          Customer::RedKey = Widgets::Color


          Now a portal to widgets located on a Customer based layout will show all the related widgets record for the current customer, but only if the value in color is "red".

          • 2. Re: Filtered related table

            Sorry, i forgot to specify that the ultimate use for the related table would be a value list.


            I was considering a conditional value list, but that got a bit tricky inside of a portal, and i found that a few portals would be a better solution for this form.


            so, i plan to make a few different related tables for each type of "project" (which can be categorized by "segments"), and these related tables would serve as value lists.  So i'd have related tables, "segment1" "segment2" etc... containing projects that belong to there respective segments.

            • 3. Re: Filtered related table

              Providing you define them correctly, conditional value lists perform in portals just as though the field is located outside the portal--this is by far a simpler approach to use.


              Don't see why you need so many separate tables. It would appear you could load all the data in one table and use it in a conditional value list or use portal filtering to view different subgroups of the total table. The above technique can be used as you need, just make the "color" field a value list formatted field instead of making it a "hardwired" connection.