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.
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?
What is your DB4S version?
Did you also
The text was updated successfully, but these errors were encountered:
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
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.
I could copy that into an execution window - or my source code; deleting comments optional.
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...
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.
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:
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.
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.
… SQL ## 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.