Loader in table while changing parameters

Ignition
1

Hello!

I have a table with a named query that has a date parameter, when I change the parameter the data load on the table but take a while as it´s large.

There is a quick way to show a loader while the new data is loading?

What I´m using now is a emptyMessage.noData.text

image

wich shows the message while there is no data at all but not when there is data.

2

Add an onChange event to the date selection to wipe the table's data before it triggers the reload.

2 Likes
3

Hello!

I´m trying adding to my change script something like:
image

def valueChanged(self, previousValue, currentValue, origin, missedEvents):
    if event.propertyName == "props.value":

        table = self.getSibling("Table_0")

        headers = []  # No columns
        data = []  # No data rows
        emptyDataset = system.dataset.toDataSet(headers, data)

        table.props.data = emptyDataset
  
        if hasattr(self.getParent(), 'updateTableData'):
            self.getParent().updateTableData()

but not working...

4

Can you show the query ? That seems way too long for just a query, even for a large amount of data.

You don't need to filter on property name in perspective, the script will only trigger for this property.

And as usual, "not working" is not a sufficient error message. We need details.
But... if you just want to wipe the table clean, why is the script so complicated ?
Something like self.getSibling('table').props.data = None should work

1 Like
5

Tip: should your column header be kWh Used (not "kW Used"). Don't confuse power and energy. Same for your other columns, I suspect.

1 Like
6

That is something you do in Vision, not Perspective. In the latter, change events are attached to just the one property.

1 Like
7

What everyone else has said, plus, I'm not sure why you are referencing a sibling, simply:

self.props.data = None

...should work.

1 Like
8

This is the table with the date parameter wich filter with the date input

image
image1058×376 27.4 KB

The data is very latge, the query

WITH MAXKW AS (
    SELECT 
        TS.CODIGO, TS.ORDEN_DNF, 
        MAX(TM.KWGEN) AS MAX_TOTAL_HIST
    FROM T_MEDIDAS_TE TM
    JOIN T_Sede TS ON TM.id_sede = TS.id_sede
    WHERE TM.timestamp BETWEEN ADD_MONTHS(TRUNC(TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS')), -12) AND TRUNC(TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS')) + INTERVAL '1' YEAR - INTERVAL '1' SECOND
      AND TS.ORDEN_DNF IS NOT NULL
    GROUP BY TS.Codigo, TS.ORDEN_DNF
),					
HISTMAXKW AS (
    SELECT 
        TS.CODIGO, TS.ORDEN_DNF, 
        MAX(TM.KWGEN) AS HISTMAX
    FROM T_MEDIDAS_TE TM
    JOIN T_Sede TS ON TM.id_sede = TS.id_sede
    WHERE TS.ORDEN_DNF IS NOT NULL
    GROUP BY TS.Codigo, TS.ORDEN_DNF
),
AVGKW AS (
    SELECT 
        TS.CODIGO, TS.ORDEN_DNF,
        TS.COD_DNF,
        TS.KWCON AS KWCON,
        TS.KWLIM AS KWLIM,
        AVG(TM.KWGEN) AS AVG_KW_GEN, 
        MAX(TM.KWGEN) AS MAX_KW_PERIOD,
        AVG(TM.KWCLT) AS AVG_KW_CLT,
        MAX(TM.KWCLT) AS MAX_KW_CLT,
        AVG(TM.KWIT) AS AVG_KW_IT,
        MAX(TM.KWIT) AS MAX_KW_IT,
        TS.DNF_BAT AS DNF,
        TS.DNF_BAT_10 AS DNF10,
        TS.PRVDNF AS PRVDNF,
        MAX(TM.PENEJE) KEEP (DENSE_RANK FIRST ORDER BY TM.TIMESTAMP DESC) AS "PENEJE",
        0 AS RAMPA
    FROM T_MEDIDAS_TE TM 
    JOIN T_Sede TS ON TM.id_sede = TS.id_sede
    WHERE TM.timestamp >= TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS')
      AND TM.timestamp < TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS') + INTERVAL '1' YEAR
      AND TS.ORDEN_DNF IS NOT NULL
    GROUP BY 
        TO_CHAR(TM.timestamp, 'YYYY'), 
        TO_CHAR(TM.timestamp, 'IW'), 
        TS.Codigo, 
        TS.ORDEN_DNF, 
        TS.KWCON, 
        TS.KWLIM, 
        TS.COD_DNF, 
        TS.DNF_BAT, 
        TS.DNF_BAT_10, 
        TS.PRVDNF
)
SELECT 
    STM.CODIGO AS "CODE",
    STM.COD_DNF AS "DNF code",
    STM.KWCON AS "kW Cont.", 
    STM.KWLIM AS "kW Lim.",
    STM.AVG_KW_GEN AS "kW Used", 

....
9

Because the change script is not on the table itself, but on the date selector.

2 Likes
10 
WHERE TM.timestamp BETWEEN 
    ADD_MONTHS(
        TRUNC(TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS')), -12
    ) AND 
        TRUNC(TO_DATE(:startdate, 'YYYY-MM-DD HH24:MI:SS')) 
        + INTERVAL '1' YEAR - INTERVAL '1' SECOND ...

Are you saving datetime as strings? (Bad)

1 Like
11

Should I fix that?

12

Dates and timestamps should always be stored as DateTime type. They can be indexed easily and filtered quickly. You also have the ability to store in UTC so that you don't have (as much) trouble with daylight savings, etc.

2 Likes
13

Ok, will try the conversion, thanks Transistor

I was doing a work around for the date string

def transform(self, value, quality, timestamp):
  
    import system

system.date.format
    formatted_date = system.date.format(value, 'yyyy-MM-dd HH:mm:ss')


    return formatted_date

will try do it straight

14

Don't import system. It's already available without importing it.

And Transistor is 200% right: use the appropriate data type.

1 Like