Is File{PROP:Label} Fixed? It always returns blank for Files

[totalhip]

@Bruce

It seems that it matters if the file is Open or Closed, and incidentally if CREATE has been called or not.
If CREATE has been called, or the file is open (My Driver string is blank in the dict) then the prop:name behaves as I suggested. If the table is closed (ie this is first access) then prop:name returns blank if the external name is not set.

Hmm. Perhaps confused or not what I am seeing in my test. For instance, code to load a memory file using FileSyncClass and FileManagerClass. Obviously, PGFile is open prior to the call to generate the select string.

LoadMemFile PROCEDURE
  CODE
  Relate:PGFile.Open()
  Relate:MEMFile.Open()
  Access:MEMFile.UseFile
  MemAccess:MEMFile.SqlSelect = GetSqlSelectPGFile()
  rLoad = MemAccess:MEMFile.Load()
  Relate:MEMFile.Close
  Relate:PGFile.Close
  RETURN

**GetSqlSelectPGFile is my example function to return a generated select string using PROP:Name.

[totalhip]

@Bruce

If CREATE has been called, or the file is open (My Driver string is blank in the dict) then the prop:name behaves as I suggested.

Would be interested to see your test code. After re-reading docs on UseFile, I re-tested with UseFile before & after the open for PGFile. No difference in what PROP:Name returns.

[CarlBarnes]

@totalhip

Here is a simple version of my test.

LOOP Ndx = 1 TO File{PROP:Fields}
  IF Ndx = 1
    SelStr = 'SELECT ' & File{PROP:Name,Ndx}
  ELSE
    SelStr = SelStr & ',' & File{PROP:Name,Ndx}
  END
END

Example of where the Condition form of CHOOSE() can be used for a little less Source, e.g.

LOOP Ndx = 1 TO File{PROP:Fields}
     SelStr = CHOOSE(Ndx=1, 'SELECT ', SelStr & ',' ) & |
              File{PROP:Name,Ndx}
END

The resulting object code will not change much as it is still an IF.

I wish David Bayliss had not overloaded CHOOSE() and instead created a separate IFF(Condition,true,false) function like you’ll find in VB. If you are not familiar with CHOOSE the other form is CHOOSE(Index, Value 1, Value 2,...Value n)

[totalhip]

@CarlBarnes

Example of where the Condition form of CHOOSE() can be used for a little less Source, e.g.

I agree Carl. That is definitely my normal coding habit too. Along with AUTO and a few others, I do blame those habits on Bayliss - Squeezing the Last Drop.

[jslarve]

SelStr = 'SELECT ' & File{PROP:Name,1}
IF File{PROP:Fields} > 1
  LOOP Ndx = 2 TO File{PROP:Fields}
    SelStr = SelStr & ',' & File{PROP:Name,Ndx}
  END
END

[totalhip]

Just to add complexity – must handle timestamp columns where a Clarion group is declared over an eight byte string. In other words, the group field plus the included date & time fields must be skipped because they are unknown to the backend.

[jslarve]

Maybe it would be easiest to use the NAME attribute like what Bruce posted here? A Proposed Convention for the Extended use of the Name Attribute

That way, you have a way of knowing what to ignore.

Capesoft’s Reflection add-on makes use of that.

[totalhip]

@jslarve

Maybe it would be easiest to use the NAME attribute like what Bruce posted here? A Proposed Convention for the Extended use of the Name Attribute

For what I need, I use {PROP:Type,Field#} to determine GROUP,DATE,TIME.
With a little bit of code, I am able to skip these fields when a timestamp is involved. As mentioned earlier, without an external name specified, my testing shows that PROP:Name returns an empty string. Yet, we know the driver, in this case, will generate select code using the Label without prefix. In my mind, this inconsistency is something that should be fixed prior to any consideration of extended use as Bruce has proposed.

[jslarve]

This would be using WHO(MyRecord,Ndx), which you can get at via PROP:Record

MyRecord &GROUP
  CODE
  MyRecord &= MyFile{PROP:Record}

[totalhip]

Again, not a big problem to parse, but not consistent with what ODBC generates - WHO returns the external name when entered and a field name with prefix when external name not entered.

IMO, consistency would be PROP:Name always returning field names matching ODBC generation (no prefix) and WHO always returning field names with prefix.