Am 25.10.22 um 05:24 schrieb Tony Rietwyk:

Hi Oliver,

Can't answer your broader question, but I suspect the reason you are seeing "No query Unable to fetch row" - error code: "" is because you are not checking for an error after the prepare.

Oh my! I wasn't even aware that a call to QSqlQuery::prepare would already validate the given query! And just for my own embarassment I also noticed that I am even ignoring the boolean return value of that method. And while I do compile my application with various compilers on Windows, macOS and Linux and have various "Clang-Tidy and Clazy" and some other "modern/core C++" checks enabled, none is complaining so far about this "ignored return statement" so far (will go and see whether other checks - if enabled - will warn about this. I am pretty sure that there must be /some/ code validator test that checks for ignored return values).

(In my little defense: I am not executing any user-provided SQL. All SQL in my application is hand-crafted and "hardcoded" SQL, and any failure would indicate a "programming error" anyway, that hopefully would be detected during manual testing - I am talking about a "one man open source app", so this is acceptable for my given situation ;))

For the record, this is also (of course, as usually in an excellent manner) documented here, so for the record:

Even noting that "Some databases choose to delay preparing a query until it is executed the first time. In this case, preparing a syntactically wrong query succeeds, but every consecutive exec <>() will fail."

The fact that the "prepare" already validates the SQL is actually good news, because it could help me to "test at runtime" whether the given SQLite plugin would support sin(), cos() etc., and if not I could fall back to some simpler "distance formula".

So thank you so much to making me aware that I should - at least - also check the result of the prepare() statement (even if it is "hardcoded and tested SQL"). ;)

Cheers, Oliver
Interest mailing list

Reply via email to