Currently, the parse error message for a query like
SELECT select #1/1a/2020#;
is
org.kde.kdb.core: Parse error: tokens left globalCurrentPos: 18 sql.length(): 19 globalToken: ";" org.kde.kdb.core: error: org.kde.kdb.core: at character 18 near tooken ";"
and Kexi, in SQL text mode, moves the cursor next to the semicolon.
The query is indeed incorrect, but the error message is misleading
because the error is in the “a” within the date literal, not the
terminating semicolon.
This is due the lack of a “fallback” rule within the DATE_OR_TIME start
condition and, because it is an exclusive condition, Flex provides its
default rule that returns nothing to the parser. Therefore, the
globalCurrentPos is not incremented and, at the end, KDbParser can
detect something went wrong, but can not pinpoint the error’s correct
location at that stage.
I added a new rule that simply returns any unrecognized character as a scan
error to the parser so that it can detect the erroneous input and present a
more accurate position of where the error is. With that change Kexi moves the
cursor next to the “a”.
I also added the same rule to the INITIAL start condition to match any
character, because otherwise it also reports the error at the position of the
semicolon in queries like the following:
SELECT 1' FROM input;
When the unexpected character is one used for quoting (i.e., ', ", or `), the
message avoid quoting the unexpected message because it is harder to read the
error depending on the font.
There was, however, another issue with Flex’s action for its default
rule: it calls the ECHO macro that, by default, is defined as write the
matched input to stdout.
This is not a problem for Kexi — in fact, i am unable to see that write
in the console —, but it messes up the output of SqlParseTest. This is
particularly important when called with the ‘-xml’ or ‘-tap’ parameters,
that need to maintain their strict format or then QtCreator or Perl’s
prove can not parse the output.
FIXED-IN:3.2.1