Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entering an SQL statement with extended characters, and selecting a blank line in Execute SQL tab confuses what SQL is executed #2311

Closed
3 of 9 tasks
chrisjlocke opened this issue Jun 30, 2020 · 3 comments
Assignees
Labels
bug Confirmed bugs or reports that are very likely to be bugs.
Milestone

Comments

@chrisjlocke
Copy link
Member

chrisjlocke commented Jun 30, 2020

Details for the issue

What did you do?

Executed a highlighted statement in the Execute SQL tab.

What did you expect to see?

The executed SQL executed.

What did you see instead?

An error where additional text was executed, creating an invalid query.

Useful extra information

Here is a screencast.
http://somup.com/cY1v11QgR1

So my SQL tab contained a number of different SQL statements, and I could select the one I wanted via highlighting, and pressing F5. This worked, but if an extra line was selected, then some characters were 'stolen' from the line following the highlighted section.
I assume this is due to CRLF / CR / LF line count issues.

Edit: OK, I just tried this is a nightly, and it worked. Tried it in a new tab, and it worked. It was the query which was causing it. If you copy the text from #2310, it was the Korean text in the middle of the queries, throwing it out. Unsure why - I guess extended characters counts as multiple characters, throwing out the counts?
Query: insert into keyValues (section,key) values ('Korean','한국어');

So, a bit of an edge case, but I'm sure it'll bite someone at some point, so in the meantime (if not easy to fix) do we add a 'known issue' Wiki entry?

The info below often helps, please fill it out if you're able to. :)

What operating system are you using?

  • Windows: ( _version:_10 ___ )
  • Linux: ( distro: ___ )
  • macOS: ( version: ___ )
  • Other: ___

What is your DB4S version?

  • 3.12.0
  • 3.11.x
  • Other: ___

Did you also

@chrisjlocke chrisjlocke changed the title Selecting a blank line in Execute SQL tab confuses what SQL is executed Entering an SQL statement with extended characters, and selecting a blank line in Execute SQL tab confuses what SQL is executed Jun 30, 2020
@justinclift justinclift added the bug Confirmed bugs or reports that are very likely to be bugs. label Jun 30, 2020
@justinclift
Copy link
Member

@MKleusberg Thoughts? Seems like a parsing problem, which is generally your wheelhouse? 😄

MKleusberg added a commit that referenced this issue Jul 5, 2020
Fix executing the selected SQL statement(s) when there are multi-byte
characters before the selection. Because QScintilla gives us the start
position of the selection in bytes and we used the value for counting
characters, the executed part of the text was off by a few characters.

See issue #2311.
@MKleusberg MKleusberg self-assigned this Jul 5, 2020
@MKleusberg
Copy link
Member

Should be fixed now 😄 @chrisjlocke Can you try the next nightly build and double check?

There was no parsing problem but just a confusion of how to specify the start of the selection: QScintilla gives us the position in bytes but we were treating it as the number of characters. For single-byte characters this makes no difference but for multi-byte character it sets off the position.

@chrisjlocke
Copy link
Member Author

Confirmed this now works with no issues. Thanks @MKleusberg 👍

mgrojo pushed a commit that referenced this issue Aug 22, 2020
Fix executing the selected SQL statement(s) when there are multi-byte
characters before the selection. Because QScintilla gives us the start
position of the selection in bytes and we used the value for counting
characters, the executed part of the text was off by a few characters.

See issue #2311.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs.
Projects
None yet
Development

No branches or pull requests

4 participants