Skip to content

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

Closed

Description

@chrisjlocke

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

Activity

  1. 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[/+] on Jun 30, 2020
  2. added
    bugConfirmed bugs or reports that are very likely to be bugs.
    on Jun 30, 2020
  3. justinclift commented on Jun 30, 2020

    @justinclift
    Member

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

  4. self-assigned this
    on Jul 5, 2020
  5. MKleusberg commented on Jul 5, 2020

    @MKleusberg
    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.

  6. added this to the 3.12.1 milestone on Jul 5, 2020
  7. chrisjlocke commented on Jul 6, 2020

    @chrisjlocke
    MemberAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugConfirmed bugs or reports that are very likely to be bugs.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions