2017-04-20 Bug v1.3.2.883 - Not displaying some database results when done until toggling UI
csuire
Posts: 25 Bronze 3
I'm running a query against a lot of databases and sometimes the UI results grid does not show all of the results when completed until I toggle between UI elements such as Messages/Results tabs, or different execution results. It does not do this every time. Sometimes it will show all of the results. Sometimes it will not. Sometimes it will start consistently showing the results until I close the program and re-run the query.
I have not seen this behavior in previous versions.
This is scary because I may go to highlight/copy the results and only get some of the data if I don't notice that some of the results are missing!
In my case, I have 958 databases total, 15 rows should be displayed in the results grid from 5 of the databases. Sometimes it will only show 5 rows, even though the status bar shows 15 rows were returned total.
When this occurs it is consistently the last two databases's results that are not in the grid.
I am running with the option of parallel execution 25 databases simultaneously.
Seems like maybe the program needs to redraw the results grid when completed one last time in some cases...
Sample of the query:
IF EXISTS(SELECT Id FROM TableX WHERE SomeTime >= '2017-04-20 00:00')
SELECT Id FROM TableX WHERE SomeTime >= '2017-04-20 00:00'
Screenshot showing (1) completed state with 5 rows in the results grid, but 15 rows in the statusbar, and (2) after toggling and the redraw of all 15 rows.
I have not seen this behavior in previous versions.
This is scary because I may go to highlight/copy the results and only get some of the data if I don't notice that some of the results are missing!
In my case, I have 958 databases total, 15 rows should be displayed in the results grid from 5 of the databases. Sometimes it will only show 5 rows, even though the status bar shows 15 rows were returned total.
When this occurs it is consistently the last two databases's results that are not in the grid.
I am running with the option of parallel execution 25 databases simultaneously.
Seems like maybe the program needs to redraw the results grid when completed one last time in some cases...
Sample of the query:
IF EXISTS(SELECT Id FROM TableX WHERE SomeTime >= '2017-04-20 00:00')
SELECT Id FROM TableX WHERE SomeTime >= '2017-04-20 00:00'
Screenshot showing (1) completed state with 5 rows in the results grid, but 15 rows in the statusbar, and (2) after toggling and the redraw of all 15 rows.
Tagged:
Comments
As you have a support contract with us I'm going to raise this as a ticket so that one of our product support engineers can have a detailed look for you. In the meantime if anyone in the community has anyone to add please dive right in :smiley:
I cannot reproduce this problem on my test system. Would it be possible for you to increase the minimum logging level to verbose (Help ->Logging ->Minimum Logging Level)?
On the next occasion the reported problem occurs, locate the current log file (Help ->Logging ->Open Current Log file or Locate log files) and send a copy of the current or latest log file to support@red-gate.com. Please also include the support ticket number #87865 as the email subject?
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
For anyone else following this issue, to reproduce this problem, you must select the results grid as soon as possible and before all of the databases are processed. If you wait until after all of the databases are processed, then you will be selecting the results grid and forcing a draw of the results. The problem is that when watching the results stream in, the program doesn’t always draw all of the results into the grid. But a forced redraw by for example clicking Messages and then Results does fix the issue.
I currently have about 1000 databases and am using 25 threads. This takes 9 seconds. That is enough time to switch to results grid under normal usage before all of the results are available.
But I just reproduced this problem with 36 databases and 25 threads, by adding a WAITFOR DELAY to the query to give me time to switch to results and watch them stream in.
I tried reproducing this issue with 5 databases and 2 threads, but wasn’t able to with a couple of attempts.
Here is the query I used for the 36 database 25 thread test that did reproduce the issue:
WAITFOR DELAY '00:00:03'
SELECT 'test'
I almost missed gathering some data the other day before I remember to use my workaround to refresh the results tab.
Simple steps to reproduce:
1. Load 4 databases. Set options to use parallel execution against 2 databases at a time.
2. Run the query below and immediately switch to the "Results" tab to watch the results come in.
3. When footer showed "Script executed successfully on 4 databases", the results only had 3 rows.
4. Switching between Messages and Results tabs redraws the results and then all 4 database results are visible.
Various combinations
Using 2 threads, I reproduced this with even number of databases (4, 6, and 8 databases). Each time is was missing 1 row of results.
Using 2 threads, I could NOT reproduce this with odd number of databases (3,5, and 7 databases).
Using 3 threads, with 7 databases, it would drop 2 rows of results until refreshed.
Using 3 threads, with 8 databases, it would drop 1 row of results until refreshed.
QUERY:
WAITFOR DELAY '00:00:05'
SELECT 'test'
I have followed your example and I still cannot recreate the reported fault symptoms. Therefore I have submitted a new Bug Report whose reference is SE-778. Hopefully my colleagues in the development team will be more successful in recreating this error and consequently create a bug fix version for it.
Many Thanks
Eddie
Senior Product Support Engineer
Redgate Software Ltd
Email: support@red-gate.com
The issue is not fixed.
Version 1.4.8 mentioned fixing something similar which is why I re-tested. This issue is not a big deal for me as I know to workaround it. But if you don't realize some results will be missing, using the partial results displayed could cause problems!
I'm curious if anyone else has run into it or can reproduce?
Simple steps to reproduce:
1. Load 4 databases. Set options to use parallel execution against 2 databases at a time.
2. Run the query below and immediately switch to the "Results" tab to watch the results come in.
3. When footer showed "Script executed successfully on 4 databases", the results only had 3 rows.
4. Switching between Messages and Results tabs redraws the results and then all 4 database results are visible.
Example Query:
WAITFOR DELAY '00:00:05'
SELECT 'test'
Note: In a real example I might run a query against 500 to 1000 databases and don't need the WAITFOR delay. The delay is only there in this simple example to give me time to switch to the results tab while the scripts are still running.
Release Notes from February 2019 that looked sort of similar:
At least it mentioned the results pane not updating in some cases...
Previous support email reply from RedGate from March 14, 2018:
Unfortunately it isn't feasible, or common practice to fix all bugs encountered in a product. Although this particular bug isn't going to be addressed within the current plans for the product, we aim to fix as many as possible.
Used version 1.4.16.1316
I could reproduce with 8 databases and 3 threads. Shows 7 results.
I could reproduce with 3 databases and serial execution. Shows 2 results.
It is inconsistent. Sometimes it will show all the results and sometimes it's missing one or more results.
1. Load 3 databases. Set options to use serial execution.
2. Run the query below and immediately switch to the "Results" tab to watch the results come in.
3. When footer showed "Script executed successfully on 3 databases", the results only had 2 rows.
4. Switching between Messages and Results tabs redraws the results and then all 3 database results are visible.
Example Query used to give enough delay to click on Results tab before all results are shown:
WAITFOR DELAY '00:00:05' --Big enough number to allow you to click script and switch to Results
SELECT 'test'
I tried this on two computers and was able to reproduce the issue on both.