FYI this "comma counting" only affects what appears in the list of "field" choices. There's nothing stopping you from hand typing, say, $10$ or $100$ into a Set Fields value, even if the drop-down shows only (say) 5 choices. Of course, your SQL had then better have at least that many columns of data for this to make sense.
An example reason for this is a "SELECT * FROM..." sql statement. Without a very complex analysis of the DB's data dictionary, or somehow trying out the SQL, there's no way for the Dev Studio to know how many columns might be returned. So, the value expression parser needs to allow you to include *whatever *$<integer>$ values you wish to include. For fun I just tried including a $200$ in a value. Worked fine. And, without any SQL, the list of field choices seems to default to showing $1$ through $10$. -c On Thu, Sep 4, 2014 at 10:43 AM, Joe D'Souza <[email protected]> wrote: > ** > > I saw it in 7.1 when I did a nested SQL statement that had many commas and > had noticed that it was number of commas + 1 that the Admin Tool back then > estimated the $ variables. Same as now. So that logic fails when you use > functions that require more than one parameters separated by a comma. > > > > I did hear that was the case pre-7.1 too.. > > > > It must be tricky when you are returning more than 1 column yeah? > Fortunately for me both back then as well as now I needed only a single > column returned by the SQL so the only value I had any interest in was $1$. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Grooms, Frederick W > *Sent:* Thursday, September 04, 2014 8:49 AM > *To:* [email protected] > *Subject:* Re: *Ancient* bug with Set Field from a SQL transaction still > present... > > > > I’m not sure if it would be the API or just the code that is used in > Developer Studio (Possibly the same code that was used in the Admin tool). > > > > When you do an SQL set fields DS does not actually run it to determine the > number of columns in the output so it just makes the best guess it can on > how many there will be. I have seen this same scenario since at least > version 5 with the Admin Tool. > > > > Fred > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Joe D'Souza > *Sent:* Thursday, September 04, 2014 6:10 AM > *To:* [email protected] > *Subject:* *Ancient* bug with Set Field from a SQL transaction still > present... > > > > ** > > I had found this bug a really long time ago on version 7.1. > > > > It still exists. > > > > I was trying Set Fields through SQL to capitalize the first letter of a > word after the 6th character so this should have returned only $1$ as a > possible choice of results. > > > > select substr('$FieldName$', 1, 6) || initcap(substr('$FieldName$', 7)) > from dual > > > > However, I get $1$, $2$, $3$ and $4$ to choose from. It appears like the > ARSystem API looks at every comma between select and from and thinks that > there are that many column values to return, which would explain the 4 > dollar columns in the result list to choose from. > > > > Fortunately using $1$ (which should have been the only choice to choose > from) gets me the right results. > > > > Has anybody else reported this to BMC Support? I had reported this years > ago but it appears like it has not yet got fixed. Fortunately, back then > too, I needed just the first column so I did not have any real problem. > > > > I have not tested to see if I need more than one column, if the $ > variables would return the right results. Also I have not tested what $2$, > $3$ and $4$ holds. Probably nulls. Or may return an error at run time if > you select them. > > > > Cheers > > > > Joe > _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: > "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
