Hello:
Suppose I wish to refer to a column. I have the alias in *text* form. What is the best way to access the column? By best, I mean a short, clear way that: 1) can be used in both reads or writes on the column and 2) is in-line: I do not want to have to define a variable with an expression and then use that in a later line.
I have the rather ugly evaluate(aliasasstr+".colname") which I have used for years on occasion. Now, I am modifying a report where I will have to use this sort of access more than a few times.
Am I overlooking something cleaner?
Sincerely,
Gene Wirchenko
EVAL() is pretty brief.
Consider standardizing the alias, for example,
USE (aliasstr) alias TARGET AGAIN IN 0
Now, the report can refer to Target.fieldname with no need to wrap it in a function.
Of course, the actual problem you're trying to solve might be more complex. Please share.
On Thu, Apr 20, 2017 at 6:14 PM, Gene Wirchenko genew@telus.net wrote:
Hello:
Suppose I wish to refer to a column. I have the alias in *text* form.What is the best way to access the column? By best, I mean a short, clear way that:
- can be used in both reads or writes on the column and
- is in-line: I do not want to have to define a variable with an
expression and then use that in a later line.
I have the rather ugly evaluate(aliasasstr+".colname")which I have used for years on occasion. Now, I am modifying a report where I will have to use this sort of access more than a few times.
Am I overlooking something cleaner?Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
On 21-Apr-2017 5:17 AM, Ted Roche wrote:
Consider standardizing the alias, for example,
USE (aliasstr) alias TARGET AGAIN IN 0
Now, the report can refer to Target.fieldname with no need to wrap it in a function.
Elegant, but am I missing something? - why not just:
USE (aliasstr) can't the report now refer to fieldname ?
On Fri, Apr 21, 2017 at 2:04 AM, AndyHC andy@hawthorncottage.com wrote:
On 21-Apr-2017 5:17 AM, Ted Roche wrote:
Consider standardizing the alias, for example,
USE (aliasstr) alias TARGET AGAIN IN 0
Now, the report can refer to Target.fieldname with no need to wrap it in a function.
Elegant, but am I missing something? - why not just:
USE (aliasstr) can't the report now refer to fieldname ?
Sure, if there was only a single table in the report, which is what I'd prefer. Although, it's more likely SELECT (aliasstr) as Gene has already opened the report somewhere else.
I suggest a USE AGAIN because I'm guessing it's already open, and assign an ALIAS to the new work area because it's likely with the variable name "aliasstr" it may already have been assigned an alias other than its tablename, which Gene would want to retain. This way, at nearly no cost, you can
USE (aliasstr) AGAIN ALIAS Target IN 0
and refer to Target.fieldname in the report and then
USE IN Target
to close the work area, leaving the original 'aliasstr' work area to do with as Gene's framework decides. Simple, temporary, and clean up after.
As a bonus, if you create the cursor in a different way, say some mock data for testing, you can use the same alias and run your tests.
On Thu, 20 Apr 2017 15:14:55 -0700, Gene Wirchenko genew@telus.net wrote:
Hello:
Suppose I wish to refer to a column. I have the alias in*text* form. What is the best way to access the column? By best, I mean a short, clear way that:
- can be used in both reads or writes on the column and
- is in-line: I do not want to have to define a variable with an
expression and then use that in a later line.
I have the rather ugly evaluate(aliasasstr+".colname")which I have used for years on occasion. Now, I am modifying a report where I will have to use this sort of access more than a few times.
Am I overlooking something cleaner?
Why not macro substitution?
&aliasasstr..colname
Note that the two dots are mandatory.
In many cases it is better to use macros because they are expanded and interpreted only one time.
For example in sql query, in filter condition, in for clauses.
Ted and Gianni,
I'm not familiar with the double dots you both used. When is this necessary?
Mike
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gianni Turri Sent: Thursday, April 20, 2017 6:36 PM To: profoxtech@leafe.com Subject: Re: Referring to a Column
Why not macro substitution?
&aliasasstr..colname
Note that the two dots are mandatory.
In many cases it is better to use macros because they are expanded and interpreted only one time.
For example in sql query, in filter condition, in for clauses.
-- Gianni
[excessive quoting removed by server]
Macro substitution generally needs a Dot - but, the 2nd dot represents the dot you normally use between the Table name and the Field. Thus 2 dots! Make sense???
-K-
On 4/20/2017 10:00 PM, Michael Glassman wrote:
Ted and Gianni,
I'm not familiar with the double dots you both used. When is this necessary?
Mike
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gianni Turri Sent: Thursday, April 20, 2017 6:36 PM To: profoxtech@leafe.com Subject: Re: Referring to a Column
Why not macro substitution?
&aliasasstr..colname
Note that the two dots are mandatory.
In many cases it is better to use macros because they are expanded and interpreted only one time.
For example in sql query, in filter condition, in for clauses.
-- Gianni
[excessive quoting removed by server]
On 21-Apr-2017 7:30 AM, Michael Glassman wrote:
Ted and Gianni,
I'm not familiar with the double dots you both used. When is this necessary?
Mike
<snip> From Help!
[. cExpression]
The optional period (.) delimiter and .cExpression are used to append additional characters to a macro. cExpression appended to the macro with .cExpression can also be a macro. If cExpression is a property name, include an extra period (cExpression..PropertyName).
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
On Thu, Apr 20, 2017 at 10:00 PM, Michael Glassman MHGlassman@pioneerdrama.com wrote:
Ted and Gianni,
I'm not familiar with the double dots you both used. When is this necessary?
Mike
Use a dot to as a delimiter to specify the end of the macro expansion when you can't leave a space between the macro and the rest of the command, so:
cTable ="Customer" &cTable.key && expands to "Tablekey" and fails, while &cTable..key && expands to "Table.key" likely what you want.
Thanks, everyone, for the explanations! Makes sense now.
Mike
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ted Roche Sent: Friday, April 21, 2017 5:05 AM To: profoxtech@leafe.com Subject: Re: Referring to a Column
On Thu, Apr 20, 2017 at 10:00 PM, Michael Glassman MHGlassman@pioneerdrama.com wrote:
Ted and Gianni,
I'm not familiar with the double dots you both used. When is this necessary?
Mike
Use a dot to as a delimiter to specify the end of the macro expansion when you can't leave a space between the macro and the rest of the command, so:
cTable ="Customer" &cTable.key && expands to "Tablekey" and fails, while &cTable..key && expands to "Table.key" likely what you want.
[excessive quoting removed by server]
-
AndyHC -
Gene Wirchenko -
Gianni Turri -
Kurt at VR-FX -
Michael Glassman -
Ted Roche