Show monitored water levels for two standpipes from one borehole

I have two installations in one borehole (1 & 2) and I want to show the max (highest) recorded groundwater level for each.

I use the following text below within the discrete graphic but this always shows one value and not both.  Like with water strikes and rises is there a way to do the same with monitoring levels? 

<<Sql(_
SELECT MIN ([MOND].[MOND_RDNG]) _
From [MOND] _
Where [MOND].[PointID] = '<<PointID>>' _
AND [MOND].[MOND_TYPE] = "WDEP" _
)>>

I tried the alternative to the above but it did not work

<<Sql(_
SELECT MIN ([MOND].[MOND_RDNG]) _
From [MOND] _
Where [MOND].[PointID] = '<<PointID>>' _
AND [MOND].[MOND_TYPE] = "WDEP" _
AND [MOND].[PIPE_REF] = "1", "2" _
)>>

Also is it possible to add text next to the graphic of the pipe ref? so it shows 1 or 2 

Parents
  • Not sure what your data structure is, I am assuming that the table you show "MOND" has a key set of PointID, ItemKey and that it allows duplicate Item Key records.  Also I am assuming this is a fence report. If so, I would think that you would have to add a discrete graphic symbol vs depth entity to the report for each of the pipes with a depth property something like

    <<Min(<<MOND.MOND_READING>>,([MOND].[MOND_TYPE] = "WDEP") And ([MOND].[PIPE_REF] = "1"))>>

    The depth property for the second entity would be:

    <<Min(<<MOND.MOND_READING>>,([MOND].[MOND_TYPE] = "WDEP") And ([MOND].[PIPE_REF] = "2"))>>

    And so on for additional pipes. You can choose the symbol for each to be the same or different.

    You could also use an <<sql>> function but the standard <<min>> aggregate function with a where clause should work here. Note you need to use access syntax for the where clause and gINT syntax for the rest in this case.

    You can add text labels in a similar manner by using 2 (or more if you have more well pipes) text vs depth entities with the same depth property as above. You will have to deal with the case when there is no data for the second or third pipe, but I would think in that case the <<min>> function would return nothing so the symbol and/or text would not print.  When using more than one text vs depth entity, interference checking will not be done between the 2 entities so they could print on top of each other if both return the same depth value.  You can get around this by using one text entity and the second text spec for the second pipe text.  Using leaders will help identify which symbol the text is associated with.  

    I have not tested this solution because I do not know enough to reconstruct your data structure for testing. There are likely many other ways to do this.

Reply
  • Not sure what your data structure is, I am assuming that the table you show "MOND" has a key set of PointID, ItemKey and that it allows duplicate Item Key records.  Also I am assuming this is a fence report. If so, I would think that you would have to add a discrete graphic symbol vs depth entity to the report for each of the pipes with a depth property something like

    <<Min(<<MOND.MOND_READING>>,([MOND].[MOND_TYPE] = "WDEP") And ([MOND].[PIPE_REF] = "1"))>>

    The depth property for the second entity would be:

    <<Min(<<MOND.MOND_READING>>,([MOND].[MOND_TYPE] = "WDEP") And ([MOND].[PIPE_REF] = "2"))>>

    And so on for additional pipes. You can choose the symbol for each to be the same or different.

    You could also use an <<sql>> function but the standard <<min>> aggregate function with a where clause should work here. Note you need to use access syntax for the where clause and gINT syntax for the rest in this case.

    You can add text labels in a similar manner by using 2 (or more if you have more well pipes) text vs depth entities with the same depth property as above. You will have to deal with the case when there is no data for the second or third pipe, but I would think in that case the <<min>> function would return nothing so the symbol and/or text would not print.  When using more than one text vs depth entity, interference checking will not be done between the 2 entities so they could print on top of each other if both return the same depth value.  You can get around this by using one text entity and the second text spec for the second pipe text.  Using leaders will help identify which symbol the text is associated with.  

    I have not tested this solution because I do not know enough to reconstruct your data structure for testing. There are likely many other ways to do this.

Children
No Data