[SOLVED] If a named query doesn't exist is Ignition supposed to return an error?

Compounding the mystery is whether or not I need to use gateway scope or client scope everywhere…

My Gateway Scheduled Event runs daily. It calls a project script immediately. At this point what scope does my system.db.runNamedQuery have to be?

This function then calls another function. Am I still in the Gateway scope?

What appears to be happening in version 8.1.7 is if a named query doesn’t exist it just gets “skipped over”. The code continues on like the query didn’t exist at all. Is this because I am calling the wrong scope? Is this a bug in 8.1.7?

Any thoughts are appreciated.

It’s all gateway scope. It should throw an exception if the query doesn’t exist.

Add logging to prove your theory that the script is even making it to the call and that it’s being “skipped” over.

Ok, this is confusing enough I am going to go through it piece by piece…

The Scheduled Gateway event gets called below. The named query on line 935 does exist.

However, the gateway logs show no errors.

  1. Did the named query actually run?

  2. Should I have gotten an error?

It looks like you have a try: block… Are you catching the exception?

Why would you expect an error if it exists? Why do you ignore the results of the query? What does your except block look like?

Yes. The function never errors out. It completes the remainder of the function (not shown in picture).

I would expect an error because I called it from gateway scope. The named query is deleting all rows from a database table so I don’t need to know the results necessarily.

If you tell me this is all the correct behavior it might explain my other problems… since I was under the assumption the database table was correctly getting deleted.


If I call a system function I would expect something to happen.

Maybe an error message stating Missing parameter: project.

To flip the script why would Ignition do nothing in this instance?

The project is allowed to be missing because it’s pulled from the script context, because this entire call chain originates from a project Scheduled Event script. I.e. the project is implicit. There is no error, your named query is executing.

Edit: or it’s what @kcollins1 is suggesting

There is a known issue in 8.1.7 regarding scheduled scripts. I just ran into it while trying to work through some scenarios here for ya (under 8.1.7). Here is an entry from release notes of 8.1.9:

Fixed an issue where scheduled script commits wouldn’t save if previous changes had already been applied within designer session. (IGN-2747)

This was causing the changes to that scheduled script definition to not update in subsequent saves in my Designer. I’m wondering if this is causing some of the confusion. I’d recommend copying the contents out from your current scheduled script definition (to preserve it) and then restart your Designer.

The documentation doesn’t match?

Events are the following:

  1. Gateway Scheduled Event calls a Project Library function.

  2. Project Library function called a named query using project scope syntax.

  3. Project Library function calls another Project Library function.

  4. Second Library function calls a named query using gateway scope syntax.

In my head I think step #2 should throw an error that an argument is missing (project). If the argument project is implicit then can I remove the argument from step #4?

I will restart in a minute.

Yeah, either documentation is wrong or I’m wrong. 50/50 chance of either :laughing:

Because the call originates from a scheduled event, which is part of a project, the project could be implicitly provided by our ScriptContext mechanism, which would allow you to call runNamedQuery without a project parameter specified. I don’t know for sure if this is happening.

1 Like

It looks like there might be some discrepancy between the docs site and the function documentation itself. Using the auto-complete stuff in recent versions shows:

I provided just the path to my named query (“project” is an optional argument):

I understand now; the Gateway first tries to find the named query in whatever project the script is running in and then falls back to Gateway Scripting Project.

While this doesn’t explain my issue of some name queries not existing I am willing to bet that is related to other problems I have found in this code.