Change Details

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; 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

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

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