Identifier was left blank or is more than *32* characters (STATIC TEMP-TABLE AND DATASET) - Forum - OpenEdge Development - Progress Community

Identifier was left blank or is more than *32* characters (STATIC TEMP-TABLE AND DATASET)

 Forum

Identifier was left blank or is more than *32* characters (STATIC TEMP-TABLE AND DATASET)

  • Anyone know the reasoning behind this error? It happens when defining static data (TEMP-TABLE and DATASET)

    Identifier was left blank or is more than <maximum> characters. (1700)     │
                                                                               │
    Identifiers, including Database names, File names, Field names and Index   │
    names, cannot be longer than <maximum> characters.                         │

    It is hard to fit unique names in 32 characters, while still remaining meaningful.  I guess I'm spoiled by the identifiers and namespaces that OO development allows (which has no counterparts in static OE data : TT/DS).

    If you have a unique temp-table name (eg "TT{1}_AdvancedPredicateMaster") then need to inject a prefix to distinguish different *instances* of the same static data {1} = _Active, _Param, _Previous, _Projected or whatever, it is quickly obvious that 32 characters is insufficient.

    Not sure where the magic 32 characters comes from, unless it is because compilers designed 32 years ago consumed an extra ten milliseconds for each character it had to read.

    Is there an ABL start-up option to allow longer identifiers on static TT/DS data?

  • I suspect it was more constrained by memory and disk consumption than CPU speed. Others who were there at the time might contribute the exact reasons.

    32 bytes is a hardcoded internal limit. There is no switch to increase this. Internally, memory is allocated expecting this to be a maximum, so increasing it is probably not trivial. You can log an enhancement to ask for this limit to be raised, but you won't see it in a service pack, and probably not in a minor release.

  • David,
     
    Log a case with support and give us the full temp-table definition.
     
    Brian

  • OK.  Case "00523036" was created...

    Nowadays  there is autocomplete and intellisense to help us do most of the typing.  And we don't have "green screens" that restrict us to lines that are 80 characters wide.  Identifiers don't need to be limited to 32 characters anymore (and it was probably a questionable restriction to begin with).

  • Autocomplete and intellisense do not help one read code.

  • Believe it or not, the 32 character limit sometimes leads to cryptic names that are not easy to read.  Especially when the first few characters are taken up by compiler prefixes (TT_{1}_InvoiceAllocationDetail or whatever).

    That length limitation is fairly arbitrary and the purpose for it might be totally outdated at this point.

    If some OE customers are happy with a shorter limit on their identifiers, then they can probably use some sort of style-cop to enforce that.

    But it shouldn't be a limitation within the language itself.

  • I do not disagree with allowing long names, as long as they are not perversely plastered all over the code because intellisense and autocomplete make it easy to do so. Prior to autocopmlete / intellisense there was a perversion called copy / paste which also, for some, eliminated the need to think about what one was pasting.

    A piece of code doing:

    assign

      tt_whatever_InvoiceAllocationDetail.id = 1

      tt_whatever_InvoiceAllocationDetail.descr = "my invoice"

      tt_whatever_InvoiceAllocationDetail.etc =  "etc"

      tt_whatever_InvoiceAllocationDetail.etc =  "etc"

      .

    Is just performing a denial of service attack against my brain.

    So a long descriptive temp-table in a global context is fine. Any code using it should be using a buffer named just right / concisely enough for the context in which it is being used.

    define buffer budetail for tt_whatever_InvoiceAllocationDetail.

    assign

      budetail.id = 1

      budetail.descr = "my invoice"

      budetail.etc =  "etc"

      budetail.etc =  "etc"

      .

  • This might help:

    The Clean Coder: A Code of Conduct for Professional Programmers  

    by Robert Martin

  • This might help:

    The Clean Coder: A Code of Conduct for Professional Programmers  

    by Robert Martin

  • I think that it would be helpful if the OE developer tools would help enforce "style-cop" rules, if there are customers who want them.  But that may be a separate conversation.    

    I was more interested in the technical aspects of this restriction/limitation.  I don't see why 32-character identifiers is better than a 100-characters or 256 characters, etc.  On the same note, I think the limit on "STREAM" identifiers is even more restrictive than a table name.  (I think it is like 10 characters or something odd like that.)

    This reminds me of the r-code segment limits that we used to run into all the time (for no particularly good reason).  Thankfully most of those r-code problems went away after upgrading to OE 11.

    OE 12 is released and I suspect that it is too late to fix these issues until the next major version.  We may be stuck with them until OE 13.

  • > I think that it would be helpful if the OE developer tools would help enforce "style-cop" rules, if there are customers who want them.  
    > But that may be a separate conversation.    
     
     
    I would expect you to be able to write rules that enforce name lengths etc.
     
     
  • @Peter Judge

    Thanks for the pointer to the code analyzer.  I wasn't aware of that yet.

    @Brian Maher

    Is there something I should expect out of logging a case with support ?  I expect they will tell me that it's just working perfectly as-is.

    (ie..32 character identifiers in ABL ought to be enough for anyone - along with 640K of ram )

  • I have a response from tech support and they confirmed that this is a limitation and that everything is behaving as expected.

    Additionally they suggested that I send feedback in thru the Idea submissions that are monitored by the Product Management team.

    I suspect the issue is based on the fact that temp-tables are internally implemented as "lightweight" database tables which exist only in the context of a session. I suspect that restrictions imposed on OE database tables are *also* imposed on static temp-tables and datasets. I had thought that there was a larger degree of separation between them, so that static temp-tables and datasets might be freed from some of the baggage that is otherwise imposed on OE database objects.

    For example, in .Net there are *lots*  of different things that can hold data - generic collections of pocos, valuetuples, or ADO.Net datasets. These are created in the context of a given process, and they can hold data that is extracted from a database. But those collection constructs don't have any code that is shared with an actual database.  There is nothing that makes them actually follow the same rules of an RDBMS database table.

  • While not for the internal "development" definition, the "external" definition can be up to 239 characters using serialize-name.

    Make it 240 and things start misbehaving, make it 242 or larger and you have yourself a memory violation.

    define temp-table ttshort

      field cc as char

      .

    def var lcc as longchar.

    create ttshort.

    temp-table ttshort:serialize-name = fill( "a", 242 ).

    temp-table ttshort:write-xml( "longchar", lcc, true ).

    message string( lcc ).

  • The memory violation with the long serialize-name is a bug.  Please report it to Tech Support.  We don't impose a limit on the length of serialize-name, and the very long serialize-name causes a buffer overrun during WRITE-XML.  The fix for this would be to impose a 128 character limit on SERIALIZE-NAME, the same limit we use for dynamic temp-table field-names.

    Regards,

    Robin