Same issue. Any updates? Tab history usually doesn't return anything. Occasionally returns results after 10 - 30 seconds. I'd prefer it worked like it did before version 10.12.5. I downgraded to 10.12.4.29949 as a temporary workaround.
I run SSMS under 3 different accounts depending on the environments I'm connecting to. Since the change from "SavedTabs.db" to "SqlHistory.db" it is now only possible to run SSMS under one Windows account at a time. To change to an instance of SSMS under a different Windows account I must first close all instances and restart the RedGateClient service. If I try to run SSMS under multiple Windows accounts I get the "Access to the path is denied" error on the 2nd instance.
I run SSMS under 3 different accounts depending on the environments I'm connecting to. Since the change from "SavedTabs.db" to "SqlHistory.db" it is now only possibly to run SSMS under one Windows account at a time. To change to an instance of SSMS under a different Windows account I must first close all instances and restart the RedGateClient service. If I try to run SSMS under multiple Windows accounts I get the "Access to the path is denied" error on the 2nd instance.
I spent some time trying to debug this issue in 10.12.6 (thinking it was an issue with my system), and have just found this thread (revealing it's a sql prompt bug)
In my case, the Tab History window takes ~20 seconds to return results, at first opening, and after every single search character is entered. (seems like it's trying to issue a new query each character). If a character is entered while it's already searching. (ie typing a letter before the 20 seconds, or typing 2 in a row) it crashes with that semaphore timeout.
While it's hanging for 20 seconds, the RedGate.SqlPrompt.SqlHistory.Server.exe chews a cpu core for the whole 20 seconds.
Running xperf on that process while it hangs shows nearly all the time is spent in mscorlib.ni.dll!System.IO.Path.GetTempPath(), notably spending most of its time in in System.IO.LongPathHelper.TryExpandShortFileName().
Running procmon while it hangs shows it reading directory properties on my appdata/local temp directory > 18,000 times, taking ~1ms per loop iteration (call -> call latency). I notice it calling against my profile directory 8.3 shortname.
Note: My temp directory is nearly empty, maybe a dozen files currently in use.
I hope this is useful.
If you have a public debug symbol server, please let me know.
Same issue. I have my "SavedTabs.db" on OneDrive (referred from RedGate_SQLPrompt_CommonUI_Options_TabMagicOptions.xml). RedGate_SQLPrompt_CommonUI_Options_TabMagicOptions.xml has not been modified by the installation, and SavedTabs.db still has the same file size. So assuming that history is still in there. But nothing is shown in SSMS. Workarounds mentioned above do not work.
Hi - would you mind sharing you managed to do this [point to onedrive rather than local drive - just mapping]? I tried a while back and kept being thwarted - always worried if my laptop goes kaput i'm going to lose my precious history!
Installed SQL History 10.13.0.31319 this morning - seems to solve the issues I've been having with SQL History. It also introduces SQL History as a tab within SSMS (the pop out window is still available by clicking the history icon in the bottom right of this tab.)
Installed SQL History 10.13.0.31319 this morning - seems to solve the issues I've been having with SQL History. It also introduces SQL History as a tab within SSMS (the pop out window is still available by clicking the history icon in the bottom right of this tab.)
Thanks - was going to ask if anyone had validated this release. That's great if it's no longer just a pop-up that disappears when you accidentally click outside of it.
Don't suppose anyone know it it is possible to merge a tab-history saved prior to rolling back version to the tab-history db maintained over last few weeks?
I installed 10.13.0.31319... so far no problems, and the history is a breath of fresh air. Still took a while to come up, but apparently I had an enormous number of SQL statements in history. I was able to easily remove everything older than a month, and when I re-opened it the response was near-instantaneous.
After upgrading to 10.13.0.31319 i got the same error than links917... "the semophore timeout period has exipired... so no, the new 10.13. does not solve the problem. I need to go back to 10.12.4.29949
Ahhh, after deleting the file SqlHistory.db it works now...seams to be a problem of the installtion...
I upgraded to 10.13.0.31319, and it resolves the semaphore error I had previously. It is rather slow to open however. I timed it twice and it took 1 minute 19 seconds to open. But the look and feel is very much improved over Tab History.
@requesttop, are you referring to the time it takes to open SQL History? I just updated to 10.13.1.31417, and it still takes 1 minute 26 seconds to open it. Running in SSMS 18.12.1.
Thank you all for saving me from doing this update. I am still running v10.12.4.29949 and will wait for some positive feedback here before I move to a newer version.
@requesttop, are you referring to the time it takes to open SQL History? I just updated to 10.13.1.31417, and it still takes 1 minute 26 seconds to open it. Running in SSMS 18.12.1.
I'm not seeing this speed issue. While it does not open immediately, it only takes a few seconds for mine. The latest version is working well so far.
@requesttop, are you referring to the time it takes to open SQL History? I just updated to 10.13.1.31417, and it still takes 1 minute 26 seconds to open it. Running in SSMS 18.12.1.
I'm not seeing this speed issue. While it does not open immediately, it only takes a few seconds for mine. The latest version is working well so far.
How large are your history files?
Does anyone have a comparison of how long it takes for the history tab in 10.12.4.29949(or older) vs 10.13.1.31417 ?
@requesttop, are you referring to the time it takes to open SQL History? I just updated to 10.13.1.31417, and it still takes 1 minute 26 seconds to open it. Running in SSMS 18.12.1.
I'm not seeing this speed issue. While it does not open immediately, it only takes a few seconds for mine. The latest version is working well so far.
@requesttop, are you referring to the time it takes to open SQL History? I just updated to 10.13.1.31417, and it still takes 1 minute 26 seconds to open it. Running in SSMS 18.12.1.
I'm not seeing this speed issue. While it does not open immediately, it only takes a few seconds for mine. The latest version is working well so far.
How large are your history files?
SavedTabs.db is 126Mb and SqlHistory.db is 145Mb.
For me: SavedTabs.db is 1.7 Mb and SqlHistory.db is 388 Mb.
Just to clarify a few things on this. The semaphore issue should be resolved in versions past 10.13.0 if it continues please could you raise a ticket with us.
If you are receiving blank tab history is it located in the non standard location of the localappdata folder?
As for the speed, the team have some changes they believe may help with this in the coming version 10.13.2, although I do not have an eta on this at this currently.
Comments
Tab history usually doesn't return anything. Occasionally returns results after 10 - 30 seconds. I'd prefer it worked like it did before version 10.12.5. I downgraded to 10.12.4.29949 as a temporary workaround.
Thinking my settings might be the problem, I changed them to this, restarted, but still the same problem.
For those who downgraded to 10.12.4, is that version available for download? For v10 on Redgate's site I see the current version only.
https://download.red-gate.com/checkforupdates/SQLPrompt/SQLPrompt_10.12.4.29949.exe
I spent some time trying to debug this issue in 10.12.6 (thinking it was an issue with my system), and have just found this thread (revealing it's a sql prompt bug)
In my case, the Tab History window takes ~20 seconds to return results, at first opening, and after every single search character is entered. (seems like it's trying to issue a new query each character). If a character is entered while it's already searching. (ie typing a letter before the 20 seconds, or typing 2 in a row) it crashes with that semaphore timeout.
While it's hanging for 20 seconds, the RedGate.SqlPrompt.SqlHistory.Server.exe chews a cpu core for the whole 20 seconds.
Running xperf on that process while it hangs shows nearly all the time is spent in mscorlib.ni.dll!System.IO.Path.GetTempPath(), notably spending most of its time in in System.IO.LongPathHelper.TryExpandShortFileName().
Running procmon while it hangs shows it reading directory properties on my appdata/local temp directory > 18,000 times, taking ~1ms per loop iteration (call -> call latency). I notice it calling against my profile directory 8.3 shortname.
Note: My temp directory is nearly empty, maybe a dozen files currently in use.
I hope this is useful.
If you have a public debug symbol server, please let me know.
Don't suppose anyone know it it is possible to merge a tab-history saved prior to rolling back version to the tab-history db maintained over last few weeks?
Ahhh, after deleting the file SqlHistory.db it works now...seams to be a problem of the installtion...
Can we turn OFF grouping?
and the cute animations?
How large are your history files?
Just to clarify a few things on this.
The semaphore issue should be resolved in versions past 10.13.0 if it continues please could you raise a ticket with us.
If you are receiving blank tab history is it located in the non standard location of the localappdata folder?
As for the speed, the team have some changes they believe may help with this in the coming version 10.13.2, although I do not have an eta on this at this currently.