4 Replies Latest reply on Aug 21, 2010 2:28 PM by basilisk2

    Really need a Portal for one field?

    AlainGrimard

      Title

      Really need a Portal for one field?

      Post

      Am creating a Database to manage projects that my organisation is implementing. Although 95% of projects are located in specific and unique country, some projects might be implemented in several countries (sometimes up to 30).

      How can I manage this 'Country' field (certainly not a Repeating field, I tried) in the Project layout Identification.

      Create a portal only with one field (the country name) where can be listed all countries?  I tried to create such a portal but fail until now.

      I want among others to use the Country Field as a sorting field for reports, presenting list of projects per country, which means that for those multi-countries projects, the same project data could be seen in different countries.

        • 1. Re: Really need a Portal for one field?
          LaRetta_1

          Hi Alain,

          Yes, I would use a different table of locations.  It would be no different than using another table for addresses or customers.  Your Project table would hold the primary ProjectID (unique, meaningless, auto-enter, FM-Generated incrementing serial number) and your Countries table would hold its own primary CountryID serial plus the ProjectID.  Each country/project combination would be a record in this Countries table.

          As you've mentioned, reporting is one advantage of splitting the 1-to-many (1:n) into related tables but there are many other reasons, such as elimination of redundant data and allowing flexibility and growth.  Repetitions should not normally be used for data.  Whenever you see a situation where you begin putting 'like' fields within one table (or wanting repetitions), it usually indicates that another table is warranted.

          UPDATE: I don't know your skill level so I will explain how to create a new country record the easy way:  Once you connect Projects::ProjectID = Countries::ProjectID in your graph, check 'Allow creation of related' (in the connection dialog at the bottom) on the Countries side.  Place a portal of Countries on your Project layout and put your country field(s) within the portal and add your countries directly there.  Don't bother placing your Countries ProjectID within the portal - it would list the same number for every portal line AND it would always match the current project record's ID anyway.  Also, if someone changed this Country Project ID, they would orphan that country record and it would disappear from the portal.

          • 2. Re: Really need a Portal for one field?
            basilisk2

            Could you not use a Value List, either referencing a Table with the list of countries in, or as non-Table based Value List?

            • 3. Re: Really need a Portal for one field?
              LaRetta_1

              The problem with a single field holding a multi-line of countries (which is what a value list would provide) is that one cannot produce a report where one Project can appear in two different sub-summary parts by Country.

              • 4. Re: Really need a Portal for one field?
                basilisk2

                Thanks. Didn't think of that - I've got drop downs and popups on my mind as I'm looking for inspiration to solve my Conditional Value List in a Portal problem... this came up on the search I did.