$OBJECT(...)$ macro anomaly

$OBJECT(table)$ mistakenly inserts schema name instead of table name. $OBJECT(column)$ does the same, and my first thought for a workaround, $COLUMNS$ does not insert anything in case a single column is selected.

Also, $OBJECT()$ macro no longer inserts declared variable names!!!

Thank you. I have submitted a new high priority ticket #SA0020609

Thank you very much.

Please see http://www.softtreetech.com/support/phpBB2/viewtopic.php?t=23812

	gemisigo wrote:
	$OBJECT(table)$ mistakenly inserts schema name instead of table name. $OBJECT(column)$ does the same, and my first thought for a workaround, $COLUMNS$ does not insert anything in case a single column is selected.

Fixed.

	gemisigo wrote:
	Also, $OBJECT()$ macro no longer inserts declared variable names!!!

Not fixed. Also, while the popup does include item Local Variables, it is not expandable and the variables themselves are not in the list. Typing "@" filters for variables and they can be selected but nothing is inserted into the editor.

In previous releases $OBJECT$ macro was not designed to display any variables, including local. If you could see them, it was unintentional.

Anyway, thank you very much for your continues and valuable feedback. We have sent you a link for the private build 6.3.170. In this build the $OBJECT$ macro should be able to handle script variables. Please let us know if it is working correctly for you.

	SysOp wrote:
	In previous releases $OBJECT$ macro was not designed to display any variables, including local. If you could see them, it was unintentional.

That's funny. I've been using that for a very long time.

	SysOp wrote:
	Anyway, thank you very much for your continues and valuable feedback. We have sent you a link for the private build 6.3.170. In this build the $OBJECT$ macro should be able to handle script variables. Please let us know if it is working correctly for you.

To be honest, there's only one snippet that uses it. Whenever I have to run dynamic SQL that is generated by code I like to see what has been generated before it is run, be it an ad-hoc query or a stored procedure. In MSSQL 2k8, PRINT developed the very bad habit of truncating its output to 8000 character for non-Unicode and 4000 characters for Unicode input. Sometimes a dynamic sql is longer than that and the laziness of PRINT makes debugging harder. Therefore I made this snippet:

	Code:
	DECLARE @multi_print_counter INT = 1 WHILE @multi_print_counter < LEN($OBJECT$) BEGIN PRINT SUBSTRING($OBJECT$ ,@multi_print_counter , 4000) SET @multi_print_counter += 4000 END

It was crude but it worked so I began using it whenever there was a VARCHAR(MAX) or an NVARCHAR(MAX) type variable involved. Now this snippet is still broken, eg. I'm able to select '@stmt' from the popup but the result still does not contain the selected variable:

	Code:
	DECLARE @multi_print_counter INT = 1 WHILE @multi_print_counter < LEN() BEGIN PRINT SUBSTRING( ,@multi_print_counter , 4000) SET @multi_print_counter += 4000 END