i have a script on a calendar that changes a few custom properties when the date is changed. One of these custom properties is using the system.tag.queryTagHistroy to take an average of the amount of "on time" there is over a given work shift (8hr/9hr depending) when i change the date, there is a couple of second delay before the data changes. This looks clunky when going through and checking out each day. Is there a way to make this delay go away? do i need to move out of the script and use jsut a table in general? here is a copy of the specific script.
Where did you put this script?
If this is a Vision propertyChange script, then you don't have any check for which property changed, and that will flood your UI with extraneous executions.
{ Always start with if event.propertyName == 'somePropName': and indent the actual code under that if. }
1 Like
It is in the calendar itself. it's how I get the other custom properties their values. but none of them are 8 tags large just 1. the changing of the date is the event.
when the date changes, then the "event" is triggered and it runs. Also, I don't understand how to use your suggestion. my understanding of what I need to do is likely less than a 5th grader at this point.
Yes, your code runs on date changes. But other things can change on that component, and those will run your code, too. Indent your code. Add the if statement above it. (With the correct property name. Shown in a tooltip if you hover over the prop in the property editor.)
ok.. I looked up how to do this and it went event slower. I commented out everything one by one and its at the same place. When the above start to gather it's data, it slows down. Is it the number of tags it's trying to look at? could it be that i have the dataset row = to 1 instead of a super large table? is it the average im trying to calculate? maybe?
Ok. Then it probably means you haven't optimized your DB. An index on the historian table's t_stamp column should be present.
Or your DB is on a wimpy system that just can't deliver/process a shift's worth of data quickly.
does this look right then? And it could be that what we are running is not "strong" enough. Something I cannot change I'm afraid..
That provides no information about the DB's indices. You would look at the DB through its workbench or some other administration tool. (I recommend DataGrip, fwiw.)
1 Like
I put it in a different location in the script and it helped a little. thanks 
I deduce that it tells you that the indices are not present.