Ctrl+Enter no longer executing only statement where cursor is

[Walkeer]

Ctrl+Enter no longer executing only statement where cursor is

[Walkeer]

dbeaver-debug.log

empty.log - renamned from .log

[E1izabeth]

Please try switching Blank line is statement delimiter setting to Always
#25061 (comment)

[Xylandor]

I agree with @Walkeer. Something has broken this since the latest update. This behavior is occurring on my RedShift and MySQL connections. It doesn't happen all the time, but I know if I have the LIMIT keyword specified, it'll happen every time.

Here's a test script. Attached is a vid showing that even though I place the cursor in the SELECT 1; line, it ignores the semi-colon and tries to execute the second LIMIT 1; line too; which throws an error.

I'm using the same DBeaver version: 24.0.3, but on a MacOS Sonoma 14.4.1, with a MySQL v8 connection.

select 1;

limit 1;

Screen.Recording.2024-04-22.at.15.49.45.mov

[Xylandor]

After testing more with the Blank line is statement delimter setting, the Smart option seems to be causing me issues. I set it back to Always and it is now working like I'm used to.

Not really sure how that Smart option is supposed to work or how it determines whether to use/ignore the semi-colon, but I believe there's something wrong with it. I don't know of a use-case where that would be a good option to use.

Looking back at the previous version (24.0.2), this was a new option added.

So, @Walkeer, I'd suggest changing this to Always to get it working like you expect.

[E1izabeth]

The fix will be included in DBeaver 24.0.4.
Also you can try Early Access version with fix https://dbeaver.io/files/ea/ now.

[E1izabeth]

Please provide the minimal script example to reproduce your issue

[Walkeer]

example script here, confirmed its able to replicate this issue:

select 1;

select 2;

[E1izabeth]

Unfortunately, I can't reproduce it. What setting value do you have here?

[E1izabeth]

Is Ignore native delimiter turned on?

[Walkeer]

I have exactly the same settings as you have. Using the latest terradata JDBC driver. Previous DBeaver version works fine as well as all older versions.

[MashaKorax]

I can not reproduce the issue.

[E1izabeth]

@Walkeer
We would kindly ask you to reproduce the issue once again. After you reproduce the issue, please send us the DBeaver log files.
The log files are generated automatically and called .log and .dbeaver-debug.log exactly. They are located in the %APPDATA%\DBeaverData\workspace6.metadata directory. Here is our wiki page on this matter: dbeaver.com/docs/wiki/Log-files/#log-files

[Walkeer]

that fixed it

[alesc2000]

"Blank line is statement delimiter: Smart" not working as expected. If I have the usual delimiter ";" at the end of the query and then a blank line, then the delimiter is ignored. In the editor it appears as a query block, which can even be collapsed.

[E1izabeth]

@alesc2000 currently it's the expected behavior

[Walkeer]

something definitly changed or broke in the very last version. "Smart" is no longer working. It also broke "Execute SQL Script". When I have the default "smart" setting and use any DML along with "Collect Statistics" statement and run "Execute SQL Script", it ends with an error. With "Always", its working as usual.

SQL Error [3576] [25000]: [Teradata Database] [TeraJDBC 20.00.00.19] [Error 3576] [SQLState 25000] Data definition not valid unless solitary.
  [Teradata Database] [TeraJDBC 20.00.00.19] [Error 3576] [SQLState 25000] Data definition not valid unless solitary.

[E1izabeth]

@Walkeer Why do you expect to execute limit 1 as a separate query? Just limit 1 is not a valid statement

[JenChampagne]

This new feature gave me an incredible amount of frustration until I set Blank line is statement delimiter to Always. I saw it happen in two cases. I don't have a reproduce case for the second case, but I do for the first.

The first case is that I've often used my script files as a bit of a scratch pad because I knew that empty lines were a delimiter anyway. Sometimes it might be some plain text, and sometimes it is a part of a query I was keeping for reference nearby or for future use.

For example, here is an minimized example in which you can see several semicolons reflecting my frustration. I didn't have a select in front of a partial query several lines later, which somehow equates to these should be the same query.

select * from mytable;;;;;;;;;;;;


-----
distinct type from mytable;

The other situation was where the second query started with do and was a plpgsql code block.

As mentioned, I've "solved" the issue by disabling "smart" mode, but it was really frustrating being automatically opted in to this. I'm not sure if "smart" mode always existed and changed, or if it's just new, but changing behaviour like this was bound to frustrate a bunch of people.

The last reply by @E1izabeth demonstrates their use cases never included partial queries, and that people who use the software differently should use it the way they use it instead. I'm not trying to pick on anyone, I just want to point out that a perspective like that is a recipe for trouble when making sudden changes.

At least in software libraries, I can generally rely on semver rules to suggest when there is a breaking change, but since I get nagged to upgrade every time I open the application, I don't generally expect to need to seek out changelogs on my own to see if something is going to sabotage my worlflow.

I hope in the future something like this at least requires being opted into.

[coleman-rik]

there's a problem with blank line as delimiter. I often have multiple statements and I only want to run the one I have my cursor over.
ex:

select * from foo;
select bar from foo1;
delete from foo there bar < 10;
insert into bar (id, some_text) values (1, 'foo');
select * from baz where add_dt > '2023-10-06';

I used to be able to place my cursor inside any of those statements, and "Execute SQL Squery" would only run the statement where my cursor was placed in.

There are no blank lines to use as a delimiter.