Date Range SQL Query Update

Hey guys,

I have a bunch of pop-up alarm windows that have a date range component that queries the alarm table. I notice a lot of times that when I open that window the date range is selected for the correct time frame but sometimes it never runs the query on the database with that date range. I have to move the date range bar a little bit for it to bring back the correct data. This only seems to happen when the client is first started. After that if the pop-up window is opened again it has the correct data in it. I don’t know if this is a window caching thing or what.

Another weird thing is that the query is set to poll every 30 seconds but never uses the correct date range until the date range is moved or adjusted.

How do I force the query to run with the correct date range the first time that the window is opened?

I’ll include a screen shot of the screen in question. You can see that there are two alarms in the date range (by the histogram on the date range) but they don’t show up in the table until the date range component is adjusted slightly.

And here it is after the slight adjustment:

What version are you running?

The newest version, 7.3.3 (b570). I’ve actually had the same behavior for a few versions now.

Ok, I’ve made a ticket to get this looked at, we’ll have to try and replicate it here.

Just an update - I’ve been unable to reproduce this behavior. Anyone else able to reproduce it?

Hey Carl,

I don’t have this problem anymore with 7.7, I think it was ok with 7.6 too (after the big alarming change). But now I use the alarm journal. FYI.

The old window was passed in a parameter to filter on a specific display path. I don’t think I have that problem anywhere else, but I’ll double check.

Here is the query on the table:

SELECT STATE_NAME, ACTIVE_TIMESTAMP, CLEARED_TIMESTAMP, (DATEDIFF(second,ACTIVE_TIMESTAMP,CLEARED_TIMESTAMP)/60.0) as Downtime FROM ALERT_LOG WHERE displaypath like '%{Root Container.AlarmGroup}%' and {Root Container.Dropdown 1.whereClause} and ACTIVE_TIMESTAMP>='{Root Container.Date Range.startDate}' and ACTIVE_TIMESTAMP<='{Root Container.Date Range.endDate}' and {Root Container.Search Field.WhereClause} order by ACTIVE_TIMESTAMP desc

Yes I'm having exactly the same type of problem. Ignition 7.6.6.

I've got a Date Range component with Startup Mode Automatic.

I've got various charts on the page with their Data properties bound to SQL including references to the date range.

On startup the date range component appears correctly.

But in the SQL queries the startDate and endDate properties of the Date Range are using the values from what they were when the window was last saved in the Designer.

Indeed I've bound a Label component's Text property to the startDate and it shows wrongly (I'd previously been doing things trying to refresh the chart's data etc but clearly the problem is with the startDate and endDate properties being reported by the Date Range).

As per the original poster's issue, making a minor adjustment to the Date Range sorts everything out.

Obviously this is unacceptable to the client as they're not seeing current data on startup.

Any ideas? Thanks.

Can you send me an export of that window please?


I have just emailed an export of the window to the support e-mail address, marked for your attention.



I emailed these on Thursday but have had no acknowledgement, either via the support system or on here. Even if you haven’t had an opportunity to investigate the problem please can you let me know that you’ve received the files. The support ticket ID is #4778. Thanks.

Hi, sorry about that! I’m on vacation right now but I’ll make sure someone got the file and takes a peek at it.

I was able to replicate this in 7.7. :neutral_face:

Now to find a fix.

[quote=“KathyApplebaum”]I was able to replicate this in 7.7. :neutral_face:

Now to find a fix.[/quote]

Thanks Kathy, was that by running the window I provided or did you build a window from scratch (and still get the problem)?

Running the window you provided with a recreated database. The fix is at QA now, and should be in the next release candidate for 7.7.2.

Thanks, how does this sit with my client who is running 7.6.6 but doesn’t have Total Support contract? :blush:

I’ve back ported the fix to 7.6.8 – it will probably make it into rc2.

But a heads up on 7.6 – it’s not a LTS version, and at this time we’re being selective about what gets back ported. It’s likely the last update to 7.6 will be in just a few months. :neutral_face:

Thanks Kathy. I hadn’t even realised there was a 7.6.7 actually.