Defect in "file section" inspector handling of semicolons

Content Authoring
1

A colleague of mine alerted me that some of my fixlets that hadn’t been changed in a while had started failing. I looked into it and it appears that the handling of semicolons / ini comments broke in version 9.5.5.193.

In the Fixlet Debugger for version 9.5.4.38, a semicolon in the value does not cause any issue:

q: lines of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: [OrderHistory]
A: Headers=False
A: Sql=set nocount on;select count (*) from [mydb].[orderHistory]
A: Sql2=set nocount on select count (*) from [mydb].[orderHistory]
A: ;Sql3=some commented out value
T: 1.211 ms
I: plural file line

q: key "Sql" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: set nocount on;select count (*) from [mydb].[orderHistory]
T: 0.999 ms
I: singular string

q: key "Sql2" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: set nocount on select count (*) from [mydb].[orderHistory]
T: 1.413 ms
I: singular string

q: key "Sql3" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
E: Singular expression refers to nonexistent object.

q: key ";Sql3" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
E: Singular expression refers to nonexistent object.

However in version 9.5.5.193 (and later), it returns these results:

q: lines of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: [OrderHistory]
A: Headers=False
A: Sql=set nocount on;select count (*) from [mydb].[orderHistory]
A: Sql2=set nocount on select count (*) from [mydb].[orderHistory]
A: ;Sql3=some commented out value
T: 0.982 ms
I: plural file line

q: key "Sql" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: set nocount o
T: 1.959 ms
I: singular string

q: key "Sql2" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: set nocount on select count (*) from [mydb].[orderHistory]
T: 1.283 ms
I: singular string

q: key "Sql3" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
E: Singular expression refers to nonexistent object.

q: key ";Sql3" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: some commented out value
T: 6.674 ms
I: singular string

@AlanM or @Aram could you verify this please? I’m also not sure that a commented out key value pair like the “;Sql3=some commented out value” line should be considered a real “key”, I guess that’s up for debate.

3

Sorry, thought that was an issue Ireported last week. Probably related but different.

In my case a value that contained a semicolon was having the character before the semicolon truncated…

Value1=abc;comment
Was returning only ab and not the expected abc

4

Actually Jason, that does sound like the same bug…see the result of the first Sql key, which should return “set nocount on;select count (*) from [mydb].[orderHistory]”:

q: key "Sql" of section "OrderHistory" of file "P:\Packages\Sql Query Job\Testing\KeySectionTest.ini"
A: set nocount o

I did search before posting but didn’t see your issue. Could you do me a favor and link to it? Thanks!

5

ahem I see I never actually posted it here and went straight to PMR, sorry.

On your test case, I would expect key ‘sql’ to return
set nocount on - but still truncate at the semicolon, as the semicolon starts an inline comment in .INI-format. I wasn’t aware the earlier version kept the semicolon and comment as part of the result.

I’d also expect your third case key ";sql3" to give no result, as the older version did.

So probably two different problems around semicolon parsing in .INI files. I guess there’s a discussion in order, for the expected behavior of semicolons. (I’d be happy with the older behavior of preserving the semicolons as part of the value, but don’t kbow whether that is technically correct)

1 Like
6

I know there’s no definitive standard for ini files, but I don’t think in-line comments should be allowed. Unless IBM wants to have escape characters in their ini format, I don’t see how they would know if the semicolon is supposed to be part of the value or an in-line comment. Not sure if percent encoding would help here.

As far as the commented out ;Sql3=some commented out value, I agree - that should be treated as a single comment and not a legitimate key/value pair.

1 Like