Sometimes I wish that there was only one character datatype and not two datatypes; char for strings less than 32k and longchar for strings larger than 32k.
What if we entertain the idea of getting rid of longchar and making character handle large strings. What would that look like?
Or maybe we should boycott character variables for all new development. Is there a performance issue of simply defining long chars instead of chars even though they will only hold a few bytes?
> Or maybe we should boycott character variables for all new development. Is there a performance issue of simply defining
> long chars instead of chars even though they will only hold a few bytes?
I think this is a reasonable approach – I tend to do the same. I have not measured performance.
-- peter
Sometimes I wish that there was only one character datatype and not two datatypes; char for strings less than 32k and longchar for strings larger than 32k.
What if we entertain the idea of getting rid of longchar and making character handle large strings. What would that look like?
Or maybe we should boycott character variables for all new development. Is there a performance issue of simply defining long chars instead of chars even though they will only hold a few bytes?
Flag this post as spam/abuse.
So, longchar is not legal in an index? What other limitations are there on longchar compared to character?
CLOB, as we call it in a table, cannot be used in indexes.
Index entries have a size limit. So even very large strings cannot be used in an index anyway. So using longchar in an index doesn't really make sense beyond the nice-to-have of a single data type supporting any length string.
off the top of my head, differences of longchar are:
- corresponding database column type is "CLOB".
- cant be used in a database index
- cant be word-indexed
- size is limited 1 gigabyte
- you can set the code page of individual longchar variables
- they export and import differently than char
So, non-trivial to unify.
perhaps. when we added longchar in version 9.something, the intent was that as much as possible, programming with longchar should be no different than programming with char.
> - size is limited 1 gigabyte
Just to clarify: CLOB is size-limited. LONGCHAR is not.
-- peter
off the top of my head, differences of longchar are:
- corresponding database column type is "CLOB".
- cant be used in a database index
- cant be word-indexed
- size is limited 1 gigabyte
- you can set the code page of individual longchar variables
- they export and import differently than char
Flag this post as spam/abuse.
Good discussion and points about the database and Matt Baker's comment.
For the purpose of this dicussion, let's exclude the database concern since even with character variables and key field lengths, a developer will need to handle assigning large strings to an indexed character field.
The DB field datatype for large strings would be clobs. The DB field datatype for 32KB strings would be character of which one would need to ensure assignments would respect index limits (188 bytes or 1024 bytes depending on whether large indexes are set I think).
From strictly an ABL standpoint, I think the biggest concerns would be performance and built-in ABL statement/function support. I think most ABL functions support longchar but there are some limitations.
A simple example is:
define variable myLongChar as longchar no-undo init 'abc'.
message myLongChar
view-as alert-box.
This will error because longchars aren't supported in input/output operations.
Note that the DEFINE statement is more strict for LONGCHAR variables (like no FORMAT allowed, strict VIEW-AS support), there are automatic conversions that the ABL perform for char types which are not allowed for longchars.
Also note that the internal storage for character and longchar variables is different and some operations have the potential of being slower for longchars, for example, assignments. How much will depend on how assignment-intensive the specific code is. The other difference is that longchar variables (like memptrs) are always NO-UNDO, so if some ABL code that uses variables of data type CHAR rely on the undo behavior, that will not work if you change them to longchars.