Show last known value of T-SQL variables in pop-up definition
If I declare variables and assign them values (either in declaration or subsequent SET/SELECT statement, it would be very helpful if SQL Prompt, along with displaying the declaration (e.g. @MyVar int (Scalar variable) in the pop-up, would display the last know value. So, if my declaration was:
DECLARE @MyVar INT = 123
the popup would show something like @MyVar int = 123 (Scalar variable).
I realize some might be rather long (string) or not displayable at all (e.g. table variables, cursors, etc.) but what appropriate showing the value that was set and last known could be very helpful in line 2,345 of the script that states AND EffDate > @MaxEffDate without having to go back to the top of the script.
Optionally, allow a "Goto Definition" option in the popup if the value of the variable has been set in code, as well as a "Return to Previous Location" option. Since the tooltip shows the actual declaration (e.g. "local variable @MyVar DATE") I would expect this action to take me to the previous location where the variable was set to a value, either through a SET or SELECT. "Return to Previous Location" would return me to the point prior to jumping to the definition.
Thus, if I am on line 817 that has WHERE col = @MyVar, and I goto the definition of @MyVar, which is on line 63, "Return to Previous Location" would return me to line 817.
Goto Definition is a function of many other IDEs.
I don't see an issue. I'm saying, if it can be determined, show it. If, at the top of my code, I state DECLARE @MyVar INT = 123; then don't set it to anything else anywhere in code, then the value is 123. I don't see how this differs any more than being able to show me unused variables.
The last known value obviously would not be known if I state DECLARE @MyVar INT = (SELECT value FROM table WHERE filter = 'MyVar') and I would not expect SQL Prompt to run the code to determine the value (it would be nice :-)), but a lot of times variables are set at the start of code with the intent of functioning more like constants and if a scan of code can determine the last known value (just like a scan of code can determine unused variables, or even a variable type to display) then capturing the value it was set to should not be an issue. The code is not being executed, just scanned.
We are all different, so I won't ditch your need or idea. But your description is a huge code-smell for me. T-SQL is not a procedural language, and beside it being very difficult to establish "the last known value" without actually running the script on data, it seem very dangerous to me to rely on an automated interpretation of the code. The programmer should read the logic behind the code - not the actual values. But hey, that's just my opinion.