3 Replies Latest reply on Sep 10, 2010 4:25 AM by Lara Hellman

    When To Use Collections

    Apprentice

      Afternoon all,

       

      I have a question about collections. From what I've read they should be avoided if possible as they slow down the database from referencing back to unused data. So the question is, under what circumstances SHOULD you use a collection.

       

      Obviously when creating a new action for a process you pretty much have to use a collection, fair enough. But when else do you need to use them? At the moment I am creating a list of Authorised users based on Cost Code/Profit Centre. Each Cost Code can have only one Profit Centre but each Profit Centre can have more than one Cost Code.  Under these circumstances I believe that it would also be necessary to create a collection from Profit Centre to Cost Code but under what other conditions would it be useful to create these collections, because most people seem to advise avoiding them like the plague.

       

      Many Thanks,

       

      Anthony Mitchell

      The AA

        • 1. Re: When To Use Collections
          Stu McNeill Employee

          Hi Anthony,

           

          From my experience it is normally collections that you don't know are there that cause the performance issues.  A good example of this is if you create a reference list object and drag it onto Incident so you can have a dropdown list on the incident window to pick an item from your reference list.  When dragging the object in Object Designer to create the one-to-one link you're prompted if you also want to create a relationship back and the answer is No.  If you click Yes then a collection to Incident is created on the reference list object.

           

          We call that an "unbounded" collection, because when you create incidents and select an item from the reference list dropdown you're adding that incident to that list item's Incident collection.  This causes a problem because when you select an item in the dropdown on the incident window that item's data is downloaded from the server (for related fields to be populated, etc) and this includes collection data.  This means that all other incidents that have ever selected that list item will get downloaded from the server and if there are enough incidents in the collection you'll see a noticeable delay and eventually "Maximum request length exceeded" errors.

           

          I hope that explains the problem which I don't think will be an issue in your case.

          1 of 1 people found this helpful
          • 2. Re: When To Use Collections
            Apprentice

            Thanks for the reply Stu,

             

            Does that mean that unbounded collections can only be Lists? Process actions wouldn't have the same kind of effect, or is it due to the way actions work that would stop that? I would have though that the collection for Add Assignment for example would work the same way.

             

            Many Thanks,

             

            Tony Mitchell

            • 3. Re: When To Use Collections
              Lara Hellman SupportEmployee

              Hi Anthony,

               

              Any object can be an unbounded collection on another object, not just Incidents - as in Stu's example.  Things like Add Assignment and Add Note are not unbounded because they can only grow so much for each IPC they are attached to.  If you have Incident 1 and add a few Notes then close Incident 1 you can't add any more notes so the collection is bounded.  Any Notes you add to Incident 2 or 3 or x are associated only to those Incidents, not Incident 1 and vice versa.

               

              In Stu's example, you can create as many Incidents as you like and always pick a list item for them, therefore, that list item's Incident collection will keep on growing infinitely.

               

              It's quite a subtle difference but it can have quite a big impact on performance. I hope the explanation above helps,

               

              Thanks,

               

              Lara