[10.0.158 BETA] - $ARGS$ & $COLUMNS$ bug (SQL Server)

[10.0.158 BETA] - $ARGS$ & $COLUMNS$ bug (SQL Server)

The $ARGS(...)$ macro delimits retrieved arguments with double-quotes. This results in invalid code.

Example snippet:

	Code:
	DECLARE $ARGS(types)$;

Result when applying it to a stored procedure with three parameters, namely @debug int, @nemde int, @aha int

	Code:
	DECLARE "@debug" int, "@nemde" int, "@aha" int;

EDIT: It seems that $COLUMNS$ suffers from the same disease.

$COLUMNS(...)$ also behaves a bit strange: if a table has computed columns defined the computed part is retrieved instead of the type. It also causes some interesting glitches in formatting, for example:

	Code:
	DECLARE @_year int ,@_quarter int ,@drop_db_stmt AS 'DROP DATABASE ' + prefix + _db_name + suffix + ';' + ch ;

Thank you very much for reporting it. I have logged both issues

Hi,

We are looking into the issues reported here. The first issue with $ARGS(...)$ macro is easily reproducible and we are going to fix it very soon. The second issue with $COLUMNS(...)$ is something we are unable to reproduce so far. Our development team is asking for a sample table DDL and a code snippet that can be used to reproduce that issue.

Certainly. Here you go.

The sample table (I added a comma in the computed column, just to make it even messier):

	Code:
	CREATE TABLE #ruin_columns ( i_dont_need_input int NOT NULL IDENTITY(1 ,1) PRIMARY KEY ,but_i_do varchar(128) NOT NULL ,computed_here AS 'yeah, I know' ) ;

A very basic snippet:

	Code:
	DECLARE @_$COLUMNS(vertical,types)$

The result:

	Code:
	DECLARE @_i_dont_need_input int , @_but_i_do varchar(128) , @_computed_here AS 'yeah, @_I know'

Any updates on this one?

According to our notes in the issue tracker, the second issue with incorrect handling of computed columns containing commas in their values or expressions hasn't been fixed yet.

Yes, I had the hunch that putting a comma there could be a real pain in the back for the code that's tasked to figure out what the h*ll to do with the heap of strings to be beaten into submission.

Thanks for the update.