SoftTree Technologies SoftTree Technologies
Technical Support Forums
RegisterSearchFAQMemberlistUsergroupsLog in
[10.0.158 BETA] - $ARGS$ & $COLUMNS$ bug (SQL Server)

 
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant View previous topic
View next topic
[10.0.158 BETA] - $ARGS$ & $COLUMNS$ bug (SQL Server)
Author Message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post [10.0.158 BETA] - $ARGS$ & $COLUMNS$ bug (SQL Server) Reply with quote
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
;

Wed Aug 29, 2018 10:48 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
Thank you very much for reporting it. I have logged both issues
Wed Aug 29, 2018 12:16 pm View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
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.
Wed Sep 19, 2018 10:59 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
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'

Wed Sep 19, 2018 3:58 pm View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
Any updates on this one?
Fri Dec 07, 2018 4:37 am View user's profile Send private message
SysOp
Site Admin


Joined: 26 Nov 2006
Posts: 7840

Post Reply with quote
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.
Fri Dec 07, 2018 10:02 am View user's profile Send private message
gemisigo



Joined: 11 Mar 2010
Posts: 2102

Post Reply with quote
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.
Fri Dec 07, 2018 10:50 am View user's profile Send private message
Display posts from previous:    
Reply to topic    SoftTree Technologies Forum Index » SQL Assistant All times are GMT - 4 Hours
Page 1 of 1

 
Jump to: 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

 

Powered by phpBB © 2001, 2005 phpBB Group
Design by Freestyle XL / Flowers Online.