I would create a new non-persistent attribute on WORKORDER and an automation script with an attribute Initialize Value launch point on the attribute you created. From there, you'll need to decide whether you want to include the primary (IE the asset/location on the WO directly) or just the ones displayed in the MULTIASSETLOCCI table. Most people don't realize that the asset/location referenced on the WO is always added to MULTIASSETLOCCI so you will almost always have 1 entry in that table for every work order. I'm going to make the assumption you DON'T want to include the primary asset and based on your message that you don't want to include when it references a location (just references to an asset).

From there, you have a few different options depending on preference and need for accuracy. It's often advantageous to work with sets that already exist in memory because fewer database queries would be required. Especially if you only intend to display this in an app like WOTRACK where MULTIASSETLOCCI already exists and has been initialized. But, the caveat there is user filters can impact your results. If I filtered the MULTIASSETLOCCI table (looking for asset=123 for example) then my counts would be off if I used that same set. Or I would have to reset the set to clear the filter, which wouldn't save me anything and would be negative from a user perspective.

If you need absolute accuracy, you're best off executing a query or getting a set that won't exist in memory. If you're only trying to approximate, you're better off using something in memory as it should be faster for the user. 

Getting the size of the set can be done a few different ways, but in general I like looping through the set if I have the records in memory. That would be accurate without executing another database query. Count will get you the actual size without iterating through the set, but if the query being executed is slow then this process will be slow because it has to execute that query again. getSize() isn't reliable so I don't use it for this purpose. 

I would create a new non-persistent attribute on WORKORDER and an automation script with an attribute Initialize Value launch point on the attribute you created. From there, you'll need to decide whether you want to include the primary (IE the asset/location on the WO directly) or just the ones displayed in the MULTIASSETLOCCI table. Most people don't realize that the asset/location referenced on the WO is always added to MULTIASSETLOCCI so you will almost always have 1 entry in that table for every work order. I'm going to make the assumption you DON'T want to include the primary asset and based on your message that you don't want to include when it references a location (just references to an asset).

From there, you have a few different options depending on preference and need for accuracy. It's often advantageous to work with sets that already exist in memory because fewer database queries would be required. Especially if you only intend to display this in an app like WOTRACK where MULTIASSETLOCCI already exists and has been initialized. But, the caveat there is user filters can impact your results. If I filtered the MULTIASSETLOCCI table (looking for asset=123 for example) then my counts would be off if I used that same set. Or I would have to reset the set to clear the filter, which wouldn't save me anything and would be negative from a user perspective.

If you need absolute accuracy, you're best off executing a query or getting a set that won't exist in memory. If you're only trying to approximate, you're better off using something in memory as it should be faster for the user. 

Getting the size of the set can be done a few different ways, but in general I like looping through the set if I have the records in memory. That would be accurate without executing another database query. Count will get you the actual size without iterating through the set, but if the query being executed is slow then this process will be slow because it has to execute that query again. getSize() isn't reliable so I don't use it for this purpose. 

I would create a new non-persistent attribute on WORKORDER and an automation script with an attribute Initialize Value launch point on the attribute you created. From there, you'll need to decide whether you want to include the primary (IE the asset/location on the WO directly) or just the ones displayed in the MULTIASSETLOCCI table. Most people don't realize that the asset/location referenced on the WO is always added to MULTIASSETLOCCI so you will almost always have 1 entry in that table for every work order. I'm going to make the assumption you DON'T want to include the primary asset and based on your message that you don't want to include when it references a location (just references to an asset).

From there, you have a few different options depending on preference and need for accuracy. It's often advantageous to work with sets that already exist in memory because fewer database queries would be required. Especially if you only intend to display this in an app like WOTRACK where MULTIASSETLOCCI already exists and has been initialized. But, the caveat there is user filters can impact your results. If I filtered the MULTIASSETLOCCI table (looking for asset=123 for example) then my counts would be off if I used that same set. Or I would have to reset the set to clear the filter, which wouldn't save me anything and would be negative from a user perspective.

If you need absolute accuracy, you're best off executing a query or getting a set that won't exist in memory. If you're only trying to approximate, you're better off using something in memory as it should be faster for the user. 

Getting the size of the set can be done a few different ways, but in general I like looping through the set if I have the records in memory. That would be accurate without executing another database query. Count will get you the actual size without iterating through the set, but if the query being executed is slow then this process will be slow because it has to execute that query again. getSize() isn't reliable so I don't use it for this purpose.