Errors cleared too late

[tlhackque]

Details for the issue

What did you do?

In the Execute SQL window, I made mistakes. Lots of mistakes.

Then I'd try to fix them - with commands that take a long time (more of my mistakes). Well, plus a largish database.

What did you expect to see?

The previous errors (syntax, etc) cleared from the screen before the commands start to execute, and the new ones appear afterwards.

What did you see instead?

The old errors remain on the screen during the execution of the next attempt.
when the attempt (usually) terminates, the new errors replace them.

It's hard to tell if the command hasn't finished, or if a new round of errors is on screen.

When I click an "execute" command, the status/error region of the screen should clear; THEN the command should execute. And FiNALLY, the next round of errors (or success!) should appear.

If necessary, add about a 1/2 sec delay (outside of the stats of course) so that it's very clear that the old information is gone and that anything on the screen is a result of the latest command.

Useful extra information

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

What operating system are you using?

• Windows: ( version: ___ )
• Linux: ( distro: ___ )
• Mac OS: ( version: ___ )
• Other: ___

What is your DB4S version?

• 3.10.1
• 3.10.0
• 3.9.1
• Other: ___

Did you also

• Try out the latest nightly version: https://github.com/sqlitebrowser/sqlitebrowser#nightly-builds
• Search for an existing similar issue: https://github.com/sqlitebrowser/sqlitebrowser/issues?utf8=%E2%9C%93&q=is%3Aissue%20

[justinclift]

I wonder if the old messages being there is useful for some people?

If they are, perhaps we should leave them like an error log? (or add a separate error log which they go into)

As a general thought, if we add some kind of "Executing new query..." output before starting the new query, that could help make it clear if the displayed errors are for a new query or the previous one.

Or, as you mention, we could just wipe the old result display first then run the query. I'm not sure of an optimal approach atm (just woke up 😉), but it shouldn't be too hard for us to figure out. 😄

[tlhackque]

Old messages on screen are just confusing once a new query has been started.

However, a log would be useful. Good idea.

Perhaps it could be formatted as sql comments in the SQL logging window. That would make cause and effect adjacent, while leaving the log window executable if you copy and paste it someplace.

select * from widgets where color = 'red'
-- 1,653 rows found
select price from widgets
-- Error: No column named "price"  (Widgets are priceless0

I could copy that into an execution window - or my source code; deleting comments optional.
But going back in time, they help - which commands worked, which had errors... And I might want to copy them into a test case or documentation... Or one could have a filter (SQL, Result log, Interwoven) - I vote for Interwoven as the default.

In fact, you could eliminate the current response log and only put the response in with the SQL log. That would save screen real-estate. But I'm not sure.

Along these lines, this log can get pretty big. Might be useful to also have a SAVE or EXPORT button (or context menu item) for the sql log window...

[justinclift]

Perhaps it could be formatted as sql comments in the SQL logging window.

Good idea. 😄

Then adding some kind of filter to that log, to choose which bits are shown definitely makes sense. Same for being able save/export the log to a file as well.

Thanks @tlhackque, this is all good stuff. 😄

[tlhackque]

Just trying to use the tool - which despite the suggestions, has been very useful. SQL is not one of my native languages, and persuading it do do what I want is a LOT easier with it than with API calls - or even a command line.

The log/execution window filter would control what's visible, not the log content. But it should control what is saved/exported. That makes it easy to strip comments for extracting code; strip code for extracting a log, or include both for documentation (or generating a test case.)

Also, the export should be the (mouse) selection, or the whole log if none. That will allow selecting just the interesting section for export.

The log may want to be persistent (e.g. along the lines of saving execution window commands).

So the logic goes:

• Save everything in the log in execution order: SQL statements, results as -- comments
• On-screen, show per a selection filter. There are 3½ useful choices:
  • Interwoven SQL & Responses (default)
  • SQL Only (current)
  • Responses only
• Export what is shown
  • If there's a selection region, lines within the selection region.
  • Otherwise entire log

And - use a suitable file extension - .log or .txt :-)

Oh, the ½ choice: for extra credit, output as seen on screen - perhaps a pdf - with the syntax highlighting., colors, line numbers... Might be useful for creating documentation, presentation slides, etc. But better to get all of something working than to over-engineer and get nothing...

I don't know how your project handles issue tracking - but if you need separate tracking issues for each item, feel free to create them. I'm rather swamped.

[mgrojo]

I liked the idea of the SQL log with results as comments, so I'm working on it. But don't expect something very sophisticated 😉

[justinclift]

It already looks like a good start. 😄

[tlhackque]

Agree! What's the Confucius saying? "The journey of 1,000 miles begins with just one step."

As I noted, getting started and getting something that works is better than over-engineering and getting nothing. Refinements will come over time. Actually, except for exporting graphics, everything on my list is pretty straightforward...

thanks for jumping in.

[mgrojo]

@tlhackque We have just released version 3.12.0 which does a better job about giving feedback to the user while a query is running, so I'll close this issue now. If you think there is still some problem, you are free to reopen it or open a new one.