[SA 9.0.157 Pro BETA] - Interfering print statement

[SA 9.0.157 Pro BETA] - Interfering print statement

Using the following snippet

Code:

$$
-- usage: alias.object operand otheralias ops.
-- p6.p5 p4!p3= p2 p1same
-- p5.p4 p3= p2 p1same
declare
@p1 varchar(255) = '$CURRENT(param1, dont_replace)$'
,@p2 varchar(255) = '$CURRENT(param2, dont_replace)$'
,@p3 varchar(255) = '$CURRENT(param3, dont_replace)$'
,@p4 varchar(255) = '$CURRENT(param4, dont_replace)$'
,@p5 varchar(255) = '$CURRENT(param5, dont_replace)$'
,@p6 varchar(255) = '$CURRENT(param6, dont_replace)$'
/*
print @p1
print @p2
print @p3
print @p4
print @p5
print @p6
*/

SELECT
CASE
WHEN @p4 + @p3 IN ('!=' ,'<>' ,'<=' ,'>=' ,'+=' ,'-=' ,'*=' ,'/=') THEN @p5
ELSE @p4
END
$$|

by typing its keyword after the period in

	Code:
	aaaa.bbbb != ccc.

will result in

	Code:
	aaaa.bbbb != ccc.bbbb

which is the desired result.
Removing the comments surrounding the print section will print the contents of the variables but it won't insert anything into the editor.

With this kind of sophisticated code automation, next logical thing would be developing a kind of AI snippet being able to output the entire procedure you have in mind after typing first few letters for the procedure name :-)

Back to the current issue. I'm not sure you can have snippet code return anything but the first result set if you want the result of the generated code execution inserted into the editor. It's very likely the snippet engine fetches output of the first print command and ends prematurely before obtaining result of the ending SELECT statement, thinking it completed the required function. In other words, it can only handle one output, and in this case, it's the print output, which is unusable from the engine's point of views.

	SysOp wrote:
	With this kind of sophisticated code automation, next logical thing would be developing a kind of AI snippet being able to output the entire procedure you have in mind after typing first few letters for the procedure name :-)

Well, this one has nothing to do with the AI, but yes, that's exactly what I'm working on :) It's already semi-sentient.

SysOp wrote:

Back to the current issue. I'm not sure you can have snippet code return anything but the first result set if you want the result of the generated code execution inserted into the editor. It's very likely the snippet engine fetches output of the first print command and ends prematurely before obtaining result of the ending SELECT statement, thinking it completed the required function. In other words, it can only handle one output, and in this case, it's the print output, which is unusable from the engine's point of views.

I'm not sure that's the case. If you replace 'print' with 'select', each statement result, even of the "SELECT CASE..." part, is neatly inserted into the code. I have many snippets that dwarf this one in complexity, containing multiple $$...$$ macros combined with $OBJECT()$ and $CURRENT()$ macros that work seamlessly together. It seems that print simply breaks further execution. What's strange, though, is that each print executes and only the result of the SELECT after them is not shown. However, you're right that the prints are useless, as far as the engine is concerned. I'm not using print to any purpose here, I just thought that it might be related to this one here.

I believe it's related. I think the print commands contribute to the output issue and they should be avoided if possible. Calling any procedures internally printing diagnostic messages and system commands like dbcc may cause similar issues if they send something to the output.

By the way, your snippets demonstrate the marvelous things one can achieve through code automation. Hats off to you.