Hi, happy new year!

I am requesting a very interesting feature which I think all of us are excited to have. Say for example you executed a query which took 30 minutes to complete and accidentally pressed F5 on another query on the same window. You will loose the results of the previous query with nothing to get them back except wait another 30 minutes or less (because of query caching). What if we the results can be saved an N amount of times back in time! 🤣 . You can implement this feature in the T-SQL History Windows feature announcement.

What do you think?

Hi bugejakurt,
Sorry for late reply: it took some time to celebrate the new year :)
You proposal is generally good. Let us talk about implementation:
1. Sometimes results are HUGE, so it will be impossible to save even 1 result set into memory and we will have to cache them to disk.
2. It also might take considerable time to save results to disk
So, maybe it should be a kind of option "add to history only for long-running queries" ? So users will be able to define some minimal execution time, when results will be automatically added to history. Additionally we can add a shortcut to place current results into history. So:
- If query runs longer than X seconds results will be added to history
- If user hits some shortcut - results will be added to history as well

Additionally, we can add some "guard" option: If query was running more then Y seconds (configurable), then we can _try_ to ask user if he really wants to run next query (resetting results). I write "_try_", because we will have to check, if it is possible to intercept standard execution.

Please write me more your thoughts, so I will be able to find a good solution.
Thank you !

Hi Admin,

Thank you for your response! You have proposed some new and interesting ideas.

I understand that saving huge amounts of data would be both time-consuming and memory intensive. So bearing in mind this limitation I think that these feature proposals would apply:

- If query runs longer than "X" seconds results will be added to history

OR

- Query results are always added to history an "N" amount back in time, however if the query result is a "Z" amount of rows long then only the top first "F" number of rows are saved.

As a general rule saving query results should be fast and efficient. If possible once the user starts query execution the fetched query results will already start to be saved in history before the query execution finishes, else if this is not possible, the query results are saved after the query execution.

In addition I think the user should be blocked from executing queries during the process when the results are saved so the user cannot stack saving processes where some of the processes in the stack have not yet finished saving. This idea were there cannot be simultaneous saving processes can slow down the user because he has to wait for the saving to finish before executing the next query. Of course once a query execution display its results, the user takes some time to scroll through the results and therefore the query results saving process can save the results during this short period of time. One of the questions important in deciding how this feature is implemented is: What is the average time it takes for results to be saved on a typical disk drive?

The "ideal" (unsure if it is possible) way of saving query results history is to always save the results in the background and simultaneously, without the user knowing. Therefore if for example the user has configured that 5 results should be saved in time, then the order of the query executions would govern which 6th result should be scrapped. Having this simultaneous approach a query results saving process could still be in process when it passes further than the maximum history which should be saved, therefore the process should be killed in this case. Of course these are some ideas, you decide which you think is best.

- If user hits some shortcut - results will be added to history as well

I agree on the above statement and I think this is a must for this feature.

Regards to the guard option, well, I think it is not bad but it should be kept as a last resort because there is not concept of history there anyways and like me 😁 the user might have got used to selecting yes.

Thank you.