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

Errors cleared too late #1448

10 tasks
tlhackque opened this issue Jun 23, 2018 · 8 comments
10 tasks

Errors cleared too late #1448

tlhackque opened this issue Jun 23, 2018 · 8 comments
enhancement Feature requests.


Copy link

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

@justinclift justinclift added the enhancement Feature requests. label Jun 24, 2018
Copy link

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. 😄

Copy link

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

Copy link

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. 😄

Copy link

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 mgrojo self-assigned this Jun 24, 2018
Copy link

mgrojo commented Jun 24, 2018

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 😉


Copy link

It already looks like a good start. 😄

Copy link

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 added a commit that referenced this issue Jun 30, 2018

## Enhancements
1.  Following suggestions in issue #1448, I've added the filename, line
references and results to the User log dock as comments. The same output
for the last query goes to the usual SQL results widget. The multiple
statement executions are therefore added while executing and not in a
block that might eventually not being executed.

2. I added a busy mouse cursor for giving hint to user when there is a query
in execution and when it has finished.

3. The cursor moves to the erroneous line if the query ends with error.

## Fixes

1. The error indicators where sometimes displaced. This was caused by
manipulations of the query before passing it to SQLite. Whitespace and
comments are discarded by SQLite, so it is better to just let it ignore
them. The only visible change seems that they might be recorded in the log or
or be decorated as error when they are adjacent to the next query.
Transaction bits are replaced by the same amount of spaces, so the
character indexing inside the query isn't perturbed.

2. The default case for the sqlite3_step has been changed to an error case
since all the possible non-error cases have already been treated.
Otherwise constraint errors in INSERT statements (for example) are not
indicated as errors, but the query execution ends anyway.
Copy link

mgrojo commented Jun 21, 2020

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

@mgrojo mgrojo closed this as completed Jun 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
enhancement Feature requests.
None yet

No branches or pull requests

3 participants