Execute Current with cursor at end of line executes subsequent statement.

In 8.0, on a Mac, if you have your cursor at the end of the line after the ; and click execute current or command+. instead of executing the current statement, it executes the next statement in the buffer. this is a change from 7.x and can be quite dangerous if you're not expecting it.

Roger, I see your point, however I've never seen a DBA write two sql statements on the same line. Perhaps you could a) check for anything more on the line to the right of the caret and if there is nothing then execute the statement to the left of the carat or b) make it configurable so we can decide? Every sql editor I've ever used over the last 15 years or so has executed the line you're on so it's become quite a habit. Matt

I've come to rely on this "bug" in my daily use of DbVis. In fact, if you think about it, the old behavior makes more sense. If I type in a statement above or before another statement, I need to add the statement delimiter to this new statement in order to make the command syntactically correct and isolated from the next statement. With the old execute current behavior, I could execute this new statement immediately after making it syntactically correct and isolated by hitting Ctrl-Period. Now, with the new Execute Current behavior ("bug" fixed), I have to hit an additional key stroke, the back arrow, to get my cursor on the statement I just typed that I actually want to execute. Using the back arrow means lifting my fingers off the keyboard home row which slows me down. I would argue that the old behavior, where, if the cursor is to the immediate right of the statement delimiter for the prior command, it indicates I want to execute the prior statement rather than the next statement. At least make it a preferences selection "If cursor is to the immediate right of a statement terminator, Execute Current will execute prior statement rather than next statement." or "Emulate original execute current behavior" In my opinion, by changing existing and expected behavior, you've introduced a bug rather than fixed one. -- Tom

Hi, The old behavior was definitely a bug, and it only worked as you describe if the caret was placed just after the delimiter (i.e., not if you had a few spaces after the delimiter). Reintroducing the bug can potentially cause other problems, so that is not really an option. We may instead consider adding a new Execute Current Line feature, which would assume that all text on the current line make up a complete statement, if you believe that would satisfy your needs. Note that it would require that the statement starts and ends on the same line. Please let us know what you think. Best Regards, Hans

I commonly create multi-line statements. If you added a new command "Execute Command Which Ends on This Line", then we'd be in business. That would solve my needs. Thanks for listening. -- Tom

Agree - that would solve the problem. Thanks, Matt

Hi, Thanks for your feedback. I have opened a ticker for this. Best Regards, Hans

Hello, this new behaviour is also confusing for me and I already executed several statements I never wanted to execute. Regards, Günther

Hi Guenther, I have added your vote for this. Best Regards, Hans

Please add my vote as well...I definitely like to be able to execute a statement I just typed in a script, without having to go back a character. I rely on this and have had several bad things happen since the behavior was changed.

Hi Jeff, Thank you and everyone else who have told us how important this is to you. We really appreciate it. In the next maintenance release, the old behavior will be restored, based on a new definition of what "current statement" means rather than relying on a bug. The new definition is "the statement containing the caret or ending on the line where the caret is placed," so as long as there is only white space after the statement delimiter, it will work as before and also work with multicharacter delimiters, multiple whitespaces after the delimiter, and other special cases that gave inconsistent behavior in previous version. Best Regards, Hans