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?
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.
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.
Thanks for pointing it out [mention:f2c3b268940943f69cb639470006dc63:e9ed411860ed4f2ba0265705b8793d05].
Although its very stupid-ish from Progress to have such a "featured bug".
[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. :)
Now we seem to be on the same page Brian. Yes I will create an enhancement request.
Thanks.
[mention:c897c4efd7814789b6aaf20f2b3bdaeb:e9ed411860ed4f2ba0265705b8793d05] - Yes plz vote. Thanks.
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.
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.
"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.
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.
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.
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.