No, I understand. I was just curious. I fixed all weird column names a very long time ago so I was wondering if it was a potential source of consternation.
From: "Bruce Chitiea" <[email protected]> To: [email protected] Date: Mon, 18 May 2020 15:33:27 +0000 Subject: Re[2]: [RBASE-L] - Using #c within SELECT - Revisited Thanks, Jan, no. Per R:SYNTAX ("... where #c is the column number shown in the output of the LIST TABLES command..."), I've failed to define and insert a column alias into a SELECT statement, so as to specify the position of a column, as in: SELECT 1 FROM HUMPTY ... ... retrieving the value from column 1 . The value of vColumn_Alias increments within a WHILE loop, walking columns of a single table: (1,2,3, ..., n ) to produce concatenated output: (Value_1 (Value_2 (Value_3 .... (Value_n I receive a literal string, instead: "(1 (2 (3 ... (n" Thoughts? and thanks. Bruce ------ Original Message ------ From: "jan johansen" <[email protected]> To: [email protected] Sent: 5/18/2020 8:05:06 AM Subject: Re: [RBASE-L] - Using #c within SELECT - Revisited Bruce, Do you actually have a column named "C#"? Jan From: "Bruce Chitiea" <[email protected]> To: [email protected] Date: Sun, 17 May 2020 20:38:54 +0000 Subject: Re: [RBASE-L] - Using #c within SELECT - Revisited All: This: SET VAR vColumn_Alias TEXT = NULL SET VAR vColumn_Alias = (CTXT(.vColumnCNT_Stp)) ... correctly resolves to this: " 1 " , being the " #c " column number, in text datatype, accepted by the SELECT command. But, when used in a SELECT statement to retrieve the value contained within Field 1: SELECT &vColumn_Alias + INTO vColumn_Text INDIC vInd + FROM Parsed_Filenames + WHERE WalkListID = .vWalkList_Stp ... the value retrieved is the literal value of the text variable: " 1 ", instead of the field value. What needs to be changed in the definition of the variable, or in its use within the SELECT statement, to retrieve the value of column number " 1 "? Sooo close. Stumped. Thanks much, Bruce Bruce A. Chitiea SafeSectors, Inc. 112 Harvard Ave #272 Claremont CA 91711-4716 [email protected] +011 (909) 238-9012 c ------ Original Message ------ From: "Bruce Chitiea" <[email protected]> To: "[email protected]" <[email protected]> Sent: 5/15/2020 5:10:50 PM Subject: [RBASE-L] - Using #c within an UPDATE ... SELECT All: Courier New font BACKGROUND For a file naming and re-naming project, several thousands of custom-delimited document filenames are to be parsed into fields within table ParsedFileNames. The field count for each record varies by class and filetype, so that the filename extension scatters over a range of fields. The goal is to copy the filename extension from whichever field it falls within, to common column DocExt, ideally as the table is being populated. To this end, during parsing, SLOCI generates a field count to be stored in a FieldCount column for each record. Since the filename extension is the last field in a parsed filename, the extension is found within Column# = FieldCount. ISSUE By itself ... SELECT ('#'+(CTXT(FieldCount))) FROM ParsedFilenames ... produces: #13 #11 . #10 ... as intended. So, I'd thought this would do the trick: UPDATE ParsedFileNames + SET DocExt = + SELECT ('#'+(CTXT(FieldCount))) + FROM ParsedFileNames + WHERE DocExt IS NULL ... which produces the error: "Illegal table name - ('#'+(CTXT(FieldCount))) (2037)" Several attempts to turn the offending string into a variable, for use as an ampersand variable, have also failed. Still working at it, but clearly not getting it. How might the column number be specified within the SELECT statement, to avoid resort to a WHERE loop or CURSOR? Many thanks, Bruce Bruce A. Chitiea SafeSectors, Inc. 112 Harvard Ave #272 Claremont CA 91711-4716 [email protected] +011 (909) 238-9012 c -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/emdaf59928-37f7-4860-a39e-91a4b7d4e199%40pathfinder. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/emd608335b-5794-4374-a6c6-86bc95fc2f86%40pathfinder. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/WC20200518150506.43004C%40jjcalibrations.com. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/em60cc7253-c469-4dbf-b816-c910fe180813%40pathfinder. -- For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php --- You received this message because you are subscribed to the Google Groups "RBASE-L" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/rbase-l/WC20200518154109.010059%40jjcalibrations.com.
