Hello !!
After the upgrade from 8.1.19 to 8.1.27, some of named query is not working.
Here the DB is PostgreSQL. In PGSQL, -- are used for commenting a line.
In the below screenshot -- are inside the single quote mark. It should be considered as string.
Note: This query is working fine in the query browser.
Thanks for the reply @Transistor !!
The issue is not how to get the desired output.
The issue is, It was working fine in the earlier version, now many placed in my project I need to do the changes, which is very time consuming work.
I'm reaching out to the community to know if anyone faced such issue. Or any code fix can be given by Inductive Automation team for this.
If I recall there was an attempt at putting in the ability to parse comments in the named queries that ended up causing issues. This might be an example of this. IA would need to confirm for sure, but if you do what @Transistor is demonstrating in this exact scenario and it fixes the issue, then that is most likely the issue. You would either need to refactor how you are doing this task or upgrade to a later version that isn't affected by this bug.
Yup. Comment parsing was taken back out. (I don't recall precisely which version, but pretty quickly.) It was an attempt to help people using SQL scripts from Ignition with the few JDBC drivers that tolerate them. Bad side effects.
JDBC natively has no idea what a SQL script is--it is only designed to handle single statements.
IGN-6957: Named query comment parsing is too simple, fails to handle quoted strings
Fixed an issue where named queries that included double dash strings would fail to execute properly.
You are correct. The SQL comment parsing logic was removed in version 8.1.28. We have created another ticket (IGN-7647) to explore a better mechanism for parsing out SQL comments.
Or just don't? Ignition is built on vanilla JDBC, and vanilla JDBC doesn't support SQL scripts nor a SQL script's comments. You'll need a full SQL parser to reliably identify comments, and that parser will need to know the quirks of different branded implementations.
I recommend marking that one "Won't fix" until JDBC formally adds support for this sort of thing. (Or adds support for colon delimited parameters, which tosses the issue back at the JDBC driver writers, where it belongs.)
Well, you hit the nail on the head there. I considered providing that additional commentary about the variety of different SQL variations and JDBC notes, but you got me covered there!
Yes, the ticket is rather low priority based on effort-reward. Thanks for keeping us honest, Phil!