One of the most irksome qualities of Toad is that editor tabs that remain open for long periods of time – say in a multi-day development of a gnarly sproc – become increasingly slow to the point of being unusable. This manifests itself as a marked delay between a keypress and the text showing up on the screen, and curiously the delay is worse at the top of the tab vs the bottom.
The only way around the slowness is to close the tab and open it up again, but that hardly counts as a solution. You lose carefully crafted temp tables being used for data validation, for example.
I brought this issue up once in Toad for MySQL but I’m disappointed to find it to be the case in the SQL Server version as well. Needless to say, no other SQL environment that I’ve tested (SSMS, dbForge, etc) suffers from this kind of slowdown. It is easy to reproduce in the sense that we constantly encounter the slowdown in our regular work, but it’s not deterministic in a way that’s convenient for debugging: there’s some black magic combination of a long-running tab, large amounts of code, and ceaseless editing including many iterations of commenting out code to test different portions.
It would be wonderful if this was somehow an issue with the parser (which really needs to be overhauled anyway), but I wanted to put this out there again. My requests here on and the beta forum all seem trivially small, but frankly they are simple bugs that should not appear in any production piece of software. Consequently, my recommendation that my company switch to the paid versions of Toad is starting to look quite foolish.