Identifier was left blank or is more than *32* characters (S

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.

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.

@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

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