Method ADD-FIELDS-FROM except list expression does not remov

Posted by Akshay Guleria on 18-Sep-2017 06:11

My aim is to create a Temp-Table for a DB table by removing N number of named (and valid) fields.

An example of how I'm trying to achieve this using sports2000 DB.

DEF VAR hTempTable AS HANDLE NO-UNDO.
DEF VAR cTableName AS CHAR NO-UNDO INIT "Customer".
DEF VAR cSkipList AS CHAR NO-UNDO INIT "Fax, Comments".
DEF VAR hBuffer AS HANDLE NO-UNDO.
DEF VAR lii AS INT NO-UNDO.

/* Create TEMP-TABLE */
CREATE TEMP-TABLE hTempTable.
hTempTable:ADD-FIELDS-FROM(cTableName, cSkipList).
hTempTable:TEMP-TABLE-PREPARE(cTableName).

hBuffer = hTemptable:DEFAULT-BUFFER-HANDLE.
REPEAT lii = 1 TO hBuffer:NUM-FIELDS:
   DISP SUBST("&1. &2", lii, hBuffer:BUFFER-FIELD (lii):NAME).
END.

 

Method ADD-FIELDS-FROM except list expression does not remove all fields from resulting TempTable. it only removes the first field from the given list of fields. Is this a known bug or something wrong with my way of doing it?

Posted by Dileep Dasa on 18-Sep-2017 06:18

Try removing space between comma and column name when you define cSkipList variable. This should work.

Code after removing space:

DEF VAR hTempTable AS HANDLE NO-UNDO. 
DEF VAR cTableName AS CHAR NO-UNDO INIT "Customer".
DEF VAR cSkipList AS CHAR NO-UNDO INIT "Fax,Comments".
DEF VAR hBuffer AS HANDLE NO-UNDO.
DEF VAR lii AS INT NO-UNDO.
/* Create TEMP-TABLE */
CREATE TEMP-TABLE hTempTable.
hTempTable:ADD-FIELDS-FROM(cTableName, cSkipList).
hTempTable:TEMP-TABLE-PREPARE(cTableName).
hBuffer = hTemptable:DEFAULT-BUFFER-HANDLE.
REPEAT lii = 1 TO hBuffer:NUM-FIELDS:
   DISP SUBST("&1. &2", lii, hBuffer:BUFFER-FIELD (lii):NAME).
END.

All Replies

Posted by Dileep Dasa on 18-Sep-2017 06:18

Try removing space between comma and column name when you define cSkipList variable. This should work.

Code after removing space:

DEF VAR hTempTable AS HANDLE NO-UNDO. 
DEF VAR cTableName AS CHAR NO-UNDO INIT "Customer".
DEF VAR cSkipList AS CHAR NO-UNDO INIT "Fax,Comments".
DEF VAR hBuffer AS HANDLE NO-UNDO.
DEF VAR lii AS INT NO-UNDO.
/* Create TEMP-TABLE */
CREATE TEMP-TABLE hTempTable.
hTempTable:ADD-FIELDS-FROM(cTableName, cSkipList).
hTempTable:TEMP-TABLE-PREPARE(cTableName).
hBuffer = hTemptable:DEFAULT-BUFFER-HANDLE.
REPEAT lii = 1 TO hBuffer:NUM-FIELDS:
   DISP SUBST("&1. &2", lii, hBuffer:BUFFER-FIELD (lii):NAME).
END.

Posted by Akshay Guleria on 18-Sep-2017 06:52

Thanks for pointing it out [mention:f2c3b268940943f69cb639470006dc63:e9ed411860ed4f2ba0265705b8793d05].

Although its very stupid-ish from Progress to have such a "featured bug".

Posted by Brian K. Maher on 18-Sep-2017 07:00

Hi Alkshay,
 
It isn’t a bug.  The documentation states that this is a comma-separated list of field names, not a comma+space delimited list of field names.  What is clearer than comma separated list?
 
Brian

Posted by Akshay Guleria on 18-Sep-2017 07:25

[mention:43713cf888d84bdcb3637e465ffa1de6:e9ed411860ed4f2ba0265705b8793d05] - Well going by your statement Progress should change the documentation in lot of places to say `<delimiter>+space delimited list`(Example: ENTRY function). In my opinion "field1,field2" should be treated same as "field1, field2" . Having a space between comma separated list usually improves readability (yes it does :-)). So skipping all the field after space without any error information is perhaps not the right way of doing it.

I don't mind having the list with or without spaces. As long as documentation is consistent (which doesn't seem to be), I'm fine with it. :)

Posted by Brian K. Maher on 18-Sep-2017 07:38

Hi Alkshay,
 
I don’t know what specifically about the ENTRY function you are referring to.  Is it that the list can have spaces after the delimiter?  That is a text function and it is required to return whatever data (including spaces) is represented by a given element number in the list delimited by the specified delimiter.  I would consider it a bug if it trimmed spaces before returning the result as it would be assuming the desired output.
 
Now, if you feel that add-fields-from should trim each element in the comma separated list before using it then that would be a change in its documented behavior.  There is nothing wrong with requesting such an enhancement (I even think it would be a good one to have), however, it does not mean that the currently documented behavior is wrong.
 
Go ahead and submit an enhancement request for this.
 
Brian

Posted by Akshay Guleria on 19-Sep-2017 00:29

Now we seem to be on the same page Brian. Yes I will create an enhancement request.

Thanks.

Posted by ezequielmontoya on 20-Sep-2017 09:10

Akshay, please let me know if I can vote for your enhancement request.

It's a matter of congruence: Progress ignores trailing spaces in character fields and variables, it should do it also in comm-separated lists.

Posted by Akshay Guleria on 20-Sep-2017 10:19

[mention:c897c4efd7814789b6aaf20f2b3bdaeb:e9ed411860ed4f2ba0265705b8793d05] - Yes plz vote. Thanks.

community.progress.com/.../method_add-fields-from_should_trim_space_characters_from_except-list_expression

Posted by ezequielmontoya on 20-Sep-2017 10:24
Posted by Marco Mendoza on 20-Sep-2017 16:20

lookup("b","a,b,c") is 2

lookup("b","a, b,c")   /* one space before "b" */  is 0

Should ignore the left trailing space? I think: no.

Posted by Thomas Mercer-Hursh on 20-Sep-2017 16:28

And, if it did ignore the spaces, what would you do when you had a case where the space was significant.  The only reason for the space is to make it more easily read by a human.  

Posted by Mike Fechner on 20-Sep-2017 22:36

"The only reason for the space is to make it more easily read by a human. "

Isn't that a good reason? In a 4GL?

Not everybody does generate every line of ABL code like you do. Maintainable and future-proof code needs to remain readable by humans. So in cases, where the list cannot contain entries with white spaces (ADD-FIELDS-FROM, the original topic) here - what would be the problem with ignoring those white spaces?

In cases with NUM-ENTRIES, ENTRY, ... we'd need an additional argument, to ignore white spaces at the beginning and end of entries. But not add methods like ADD-FIELDS-FROM, ATTACH-DATA-SOURCE, etc.... where the ABL knows, the entries must be field names.

Posted by Akshay Guleria on 21-Sep-2017 01:05

Exactly my reason [mention:6e3b17cb0ff148039a2aabb4c7834ce4:e9ed411860ed4f2ba0265705b8793d05]. Thanks.

Also if at all having a space is a problem then why not throw error rather then silently truncating all the fields after the space.

Posted by Marco Mendoza on 21-Sep-2017 21:14

It is not truncating all the fields after the space; it just skip the one with the space, but if there are more fields without space they are finded correctly.

Posted by Akshay Guleria on 22-Sep-2017 00:41

That's simply great. It's even inconsistent in skipping fields.

Example 1: "Fax, Comments,Email,Discount". Fax and Discount fields are skipped but Comments and Email are not.

Example 2: "Fax, Comments,Email". Fax field is skipped but Comments and Email are not.

I think the important thing is to make this consistent either this way or that way. So

1. either the ADD-FIELDS-FROM method (which expects field names) skips spaces from the list OR

2. should throw appropriate error info so that the users know not to have spaces in the list.

This thread is closed