[SA 9.0.151 Pro BETA] - Behavioral change in $CURRENT(...)$

[SA 9.0.151 Pro BETA] - Behavioral change in $CURRENT(...)$

A quote from the help:

	Quote:
	Escapes quotes – this behavior-control option instructs the macro processor to return quotes and brackets as they are specified in quoted names and do not remove them. By default all quotes and brackets are removed. For example, text "here [comes name]" is parsed as "here" and "comes name" without that option, and as "here" and "[comes name]" when that option is chosen.

Has the way "Escape quotes" is handled changed in v9? In 7.x it actually 'escaped' quotes by duplicating them (that is, it changed ' to '', or '' into ''''). It made converting static sql into dynamic sql a piece of cake and I practically utilized the hell out of it.

Now, according the help, this functionality is gone, and instead of adding quotes to the 'current', it should remove it. I can see the use of this (by the way, it doesn't seem to work, it removes neither brackets ([ and ]) nor quotes (' or ")), because it could be used turning dynamic sql into static one, which comes in handy sometimes, but I still think that the other way around (static -> dynamic) would be a much more frequent use.

Could you bring the old functionality back, and rename this new one to "Remove quotes", please?

$CURRENT(paramx)$ also seems to have lost its capability to fetch individual tokens and grabs qualified names instead. I get very weird results. The snippets are:
Snippet 1:

	Code:
	p1:($CURRENT(param1)$) p2:($CURRENT(param2)$) p3:($CURRENT(param3)$) p4:($CURRENT(param4)$) p5:($CURRENT(param4)$) p6:($CURRENT(param5)$) p7:($CURRENT(param6)$) p8:($CURRENT(param7)$) p9:($CURRENT(param8)$)

Snippet 2:

	Code:
	p1:($CURRENT(param1, names_only)$) p2:($CURRENT(param2, names_only)$) p3:($CURRENT(param3, names_only)$) p4:($CURRENT(param4, names_only)$) p5:($CURRENT(param5, names_only)$) p6:($CURRENT(param6, names_only)$) p7:($CURRENT(param7, names_only)$) p8:($CURRENT(param8, names_only)$) p9:($CURRENT(param9, names_only)$)

Test text 1:

	Code:
	a1.b1, a2.b2, a3.b3, a4.b4, a5.b5, a6.b6, a7.b7, a8.b8

Test text 2:

	Code:
	a1.b1 a2.b2 a3.b3 a4.b4 a5.b5 a6.b6 a7.b7 a8.b8

Results for snippet 1 + data 1:

	Code:
	a1.b1, a2.b2p1:(b11) p2:(a11) p3:(.) p4:(.) p5:(a8) p6:(b6) p7:(,) p8:(,) p9:()

Absolutely not what I'd expect.

Results for snippet 1 + data 2:

	Code:
	a1.b1 a2.p1:(b11) p2:(a11) p3:(a10) p4:(b8) p5:(a7) p6:(a5) p7:(b2) p8:() p9:()

This one does not look very good either.

Unfortunately I cannot check it anymore, but if I recall correctly, SA7 would return each name part (that is, b8, a8, b7, a7) and the commas as separate tokens (for data 1, and without the commas for data2).
Results for snippet 2 + data 1:

	Code:
	p1:(a11.b11) p2:(a9.b9) p3:(a6.b6) p4:(a2.b2) p5:() p6:() p7:() p8:() p9:()

Again, not what I'd expect.

Results for snippet 2 + data 2:

	Code:
	p1:(a11.b11) p2:(a9.b9) p3:(a6.b6) p4:(a2.b2) p5:() p6:() p7:() p8:() p9:()

It looks like the snippets using the names_only option are omitting an ever increasing number of names (first a10.b10, then a8.b8 and a7.b7, then a5.b5, a4.b4, and a3.b3, etc) regardless of the input text and that's what was expected (I mean the results not to differ, not the actual results themselves).

After further tests with

	Code:
	p4:($CURRENT(param4)$)

and

	Code:
	p5:($CURRENT(param5)$)

consequently return

	Code:
	a1.b1, a2.b2, a3.b3, a4.b4, a5.b5, a6.b6, a7.b7, a8.b8, a9.b9, a10.p4:(b10) a11.b11 a1.b1, a2.b2, a3.b3, a4.b4, a5.b5, a6.b6, a7.b7, a8.b8, a9.b9, a10p5:(.)b10 a11.b11 a1.b1 a2.b2 a3.b3 a4.b4 a5.b5 a6.b6 a7.b7 a8.b8 a9.b9 a10.p4:(b10) a11.b11 a1.b1 a2.b2 a3.b3 a4.b4 a5.b5 a6.b6 a7.b7 a8.b8 a9.b9 a10p5:(.)b10 a11.b11

for test texts 1 and 2
and snippets

	Code:
	p4:($CURRENT(param4, names_only)$)

and

	Code:
	p5:($CURRENT(param5, names_only)$)

turn their respective input texts into

	Code:
	a1.b1, a2.b2, a3.b3, a4.b4, a5.b5, a6.b6, a7.b7, p4:(a8.b8), a9.b9, a10.b10, a11.b11 a1.b1, a2.b2, a3.b3, a4.b4, a5.b5, a6.b6, p5:(a7.b7), a8.b8, a9.b9, a10.b10, a11.b11 a1.b1 a2.b2 a3.b3 a4.b4 a5.b5 a6.b6 a7.b7 p4:(a8.b8) a9.b9 a10.b10 a11.b11 a1.b1 a2.b2 a3.b3 a4.b4 a5.b5 a6.b6 p5:(a7.b7) a8.b8 a9.b9 a10.b10 a11.b11

I got to the conclusion that in V9 the CURRENT macro with paramx options is intended to only use one paramx per snippet, which seems to be a huge step taken backwards. I recall myself asking a feature improvement that included paramx option being able to fetch qualified names but if you check that post here, it was meant as an addition (using options like Escape quotes) and not a replacement for the current (at that time) behavior. That way it was a tedious job to create and modify a snippet, and while this new behavior made its use much easier, it made it severely limited as well.

PS There's inconsistency in help: the screenshot shows option "Do not delete", while the live dialog (and help text) both show "Do not replace".

Last edited by gemisigo on Mon Oct 10, 2016 9:07 am; edited 1 time in total

Thank you very much for the provided examples and test cases. We are investigating this issue.

I believe this has been fixed in the latest version 9.0.157

I believe this has been fixed in the latest version 9.0.157

Cursory checks show that this one is fixed indeed. I'll put it to some stress-testing as soon as I get some time for it.
Thank you very much.

EDIT:
The new fix performs excellent when using hotkey (alt + num) but it still shows discrepancy between the new and old behavior when triggering snippets via last key. While the old one did not consider the snippet name as param, the new one does, which in turn does not make much sense to me. Could you show any use cases for that?

Also, it's still not escaping quotes.

Could you restore the old functionality of the escape quotes, please? Or at least re-add it under a different option name?

I have passed your feedback to the team. When I get a reply, I will post it here.

Thank you very much.

	gemisigo wrote:
	Could you restore the old functionality of the escape quotes, please? Or at least re-add it under a different option name?

It got restored silently, I guess 9.0.166 is to 'blame'. Though the help now does not match behavior. Nevertheless, I thank you very much for bringing this back, I missed it dearly.

The notes attached to the ticket indicate the previous behavior was unintended, caused by misunderstanding of the issue resulting in an incorrect fix.