In many cases a table will have more than one record associated to a pipe. This is the case in most work management tasks that might be used as part of a rehab tree or risk analysis. Some examples are:
SSO records: An asset might have multiple SSOs associated to it. One example of how they are used in Info360 Asset is as a 'Count of SSOs' LoF.
Pipe Repairs: An asset might have multiple historical repairs. They can be used in a rehab tree by comparing the date of the latest repair (MAX) with the date of CCTV.
This can be expanded to more summary statistics such as SUM, AVG, etc. As a first pass, solving the problems stated above should be sufficient.
IMPORT ASSUMPTIONS:
To import custom tables with one-to-many records. The data will be imported the same way it currently works.
If a pipe has more than one record associated to it all records should be imported and displayed under the asset details page.
RISK ANALYSIS ASSUMPTIONS (See Mockup):
User Creates component, sets component name, type=custom table, Data Source, and field.
After choosing field, it should have an additional option called "summary Statistics" that shows the options Count, Max, Min, and SUM (can be expanded).
There should also be a 'None' option and with this option the assumption is that it is NOT a one-to-many table and it will choose the first value it 'sees' even if it there are duplicates. This is the way IAP does it and it is a reasonable assumption to make.
Everything else works the same way as it does now.
REHAB ANALYSIS ASSUMPTIONS (See mockup):
Same concept as Risk.
Disclaimer: The development, release, and timing of any features or functionality described or discussed for our products in this User Feedback Forum for Autodesk Water Products and Services remains at our sole discretion. This User Feedback Forum for Autodesk Water Products and Services is not a commitment, promise, or legal obligation to deliver any functionality, is intended solely to outline and gather feedback about our general product direction, and should not be relied on in making purchasing decisions.
This feature requires careful thought and consideration. Custom / user data tables are not designed for this. We will need a rethink of this capability if we want to support 1:many.