7 Replies Latest reply on May 6, 2013 8:24 AM by philmodjunk

    Two layouts with same portal in both

    JohhnyHilly

      Title

      Two layouts with same portal in both

      Post

           I need some advice on using the same portal on two layouts. I have two layouts (based on the same table) with a portal on each of these layouts (linked to the same table as the other portal).

           In the one portal I have a field (say XX) that has a "Not Empty" validation. In the second portal when I try to enter data into the other field (say YY), it says "THIS FIELD (referring to the first layout/portal field XX) requires a value" . From this I am assuming each row in the either portal is the same record. Can someone please confirm this?

           The reason I am asking this is that in the first portal, I am creating a new record/row every day which is based on date. In the second portal, I am only creating a record/row once every 2 months which is also based on date, but I would like to have the data stored on the same table. Can someone recommend what I should do? Should I look at creating a new table for the second portal? I am wanting to do a calculation based on the results of both portal fields so was thinking it might be easier having them in the same table.

           Hope it is clear. Thanks in advance.

        • 1. Re: Two layouts with same portal in both
          philmodjunk

               Portals and layouts are based on Tutorial: What are Table Occurrences?. The occurrences, in turn, refer to specific data source tables. If your layouts refer to the same table occurrence, if your portals refer to the same table occurrence, if any portal filter settings are identical and if you are still on the same current record in the layout's table, then the records you see in the portal on one layout are exactly the same records that you see in the other.

               It sounds likely that this data should be recorded in the same table, but there's not enough info to go on here to be sure.

          • 2. Re: Two layouts with same portal in both
            JohhnyHilly

                 Thanks for the confirmation Phil. The way I have the tables set up, yes it should be recorded in the same table (Service HIstory if you remember), however, with the way I have the layouts/portals set up the entry of the data for YY wouldn't be a good place for it.

                 In the first portal, I have a lot of fields such as equipment running hours for data entry, where each row/record is based on the date, where a new one is created on a daily basis. The second portal however only has two fileds, date and quanity/reorder of stock for filters. Every 2 months or so the client would get say 50 new filters for a specific vessel, so on that date the user would enter 50 into the quanity field. So as you can see it's not really the same in terms of data entry because of the nature of the two layouts.

                 So this brings me to the question, if I have the same record on the two different portals with 2 different dates, they will be conflicting with each other correct? So would that mean I would need a new table for the date and quantity/reorder of stock fields? Or is there someway to keep them in the same table (Service History) as the first portal data?

            • 3. Re: Two layouts with same portal in both
              philmodjunk

                   Why can't you have two different reords in the same Service History table?

                   A portal filter can keep the records in Layout 1 from being visible in the portal to the same table in Layout 2. And you might just put both portals on the same layout--perhaps in different panels of a tab control.

                   Separate tables for very different types of Service History is an option, but you need to evaluate all possible ramifications of that design change before you make it.

              • 4. Re: Two layouts with same portal in both
                JohhnyHilly
                     

                Why can't you have two different reords in the same Service History table?

                Because at the moment, in Layout 1 portal, a new record is being created every day and assigned a date. In Layout 2 portal, this record is showing (although I can select which fields to see which I don't want to see any from Layout 1). But in Layout 2, I am not needing to enter data every day. The purpose of Layout 2 is that when new items are sent to the vessel, the date and quantity is recorded which is not every day. It's only once every 2 months. So those dates are conflicting. Is that clear?

                Also, I have a field in Layout 1 portal that is validated as "Not Empty", so when I try to enter a value in Layout 2 portal and the field value in Layout 1 doesn't have a value, it prevents me from entering data into the record because of that validation.

                How would I go about using a filter to prevent the records in Layout 1 showing up in Layout 2. Sorry but I haven't used portal filtering before. I would like to keep the portals on different layouts.

                • 5. Re: Two layouts with same portal in both
                  philmodjunk

                       It is clear and that's why I posted:

                       

                            A portal filter can keep the records in Layout 1 from being visible in the portal to the same table in Layout 2. And you might just put both portals on the same layout--perhaps in different panels of a tab control.

                       Thus the record you create in the portal on one layout need not be visible in the portal on the other.

                       (It was a rhetorical question wink)

                       Please note that I have not indicated that you shouldn't use separate tables. Ultimately, that may be the best approach. It's just that this is not a simple decision to make, you have to look over all your options and system requirements before making that call either way.

                       Have you looked up portal filters in FileMaker help? While I would have written the info a bit differently, they do give you examples of how to set up a filter and how they need to work.

                       If you go with filtered portals and keeping this data all in the same table, you'll need to modify your validation option so that creating a record in the second layout's portal does not trigger a validation error. You may need to use a calculation instead of just selecting the "not empty" check box.

                        

                        

                  • 6. Re: Two layouts with same portal in both
                    JohhnyHilly

                         Haha ok, rhetorical questions are difficult to pick up over text.

                         To be honest with you, I don't know databases well enough to know which would be better with regards to keeping it in the same table or having it in a new one. Ultimately I am not fully aware of the type of ramifications I could come across in the future if the wrong one was chosen. For the moment, I am setting it up with two tables. It's working well for the calculation that comes out of it. I guess I will see if I run into any troubles in the future with it.

                          

                    • 7. Re: Two layouts with same portal in both
                      philmodjunk

                      One Table or Two?

                           Whether it is best to include such data in one table or two requires investigating the following:

                           What kind of reporting might you need to do with this data?

                           If you need a report that lists both kinds of data in the same report, a single table is most often the better way to go. But as you are finding, the data entry side of things may need to be a bit more complex to manage the data entry process with data in the same table.

                           How different is the data to be recorded?

                           If there are no fields in common save maybe an ID number, then it makes more sense in many cases (save the reporting issue), to use separate tables. Where this becomes a judgment call is when you have a situation where you have a few fields in common and a number of fields that will be specific to one or the other of the two types of data you are recording. It can then become a judgement call that can go either way.

                      Validation and Portal Filter Calcs

                           Both of these have a lot in common. Both are boolean calculations. In otherwords they are calculations that must return a result of True in order for the data to be accepted as "valid" or for the related record in the portal to be displayed. In both cases, you are limited to a single calculation, but (also in both cases) you can use the boolean operators: And, Or, xor to combine different terms that test for different situations. And if your calculation returns a number value, any result except zero or null (empty field) will be interpreted as True. Values of 0 or Null will be interpreted as False.

                           In your validation rule, if a field must be not empty and also greater than another value, you can use And:

                           Not IsEmpty (Self) And Self > ....

                           But you'll need to be more creative than that as it appears that "Not IsEmpty ( Self ) should not apply when you are entering data into the portal on the second layout so you'll need to include some additional term so that the expression can evaluate as true when a valid new record is added via the second layout. Your expression, for example, might check for data in some field that only receives data when it is a record added via the second layout:

                           Not IsEmpty ( LayoutTwoFieldNameHere ) Or ( Not IsEmpty ( Self ) Or Self > .... )

                           Filter expressions are much the same. FileMaker checks each related record that would normally appear in the portal if there were no filter and only displays those for which the portal filter calculation evaluates as True.

                           Example: you have an equipment list of many items and a portal lists this equipment for a given vessel via a VesselID based relationship. If you then added a filter expression to the portal, this list might be reduced to show a much smaller number of items of equipment for that vessel. You might, for example use:

                           EquipmentList::Location = "Bow"

                           to limit the listed equipment to only the equipment in EquipmentList located in the Bow of the vessel.