bump.. Since the OP I have observed that a CHAR(n) field is mapped to a string, it may be padded OR trimmed, even on the same version of JPA (either JPA1.2.3 OR JPA2.0.2). The behavior appears to be by table. Eg in one table where the column CHAR(2) the values come back padded:
'C ' '1 ' 'X ' 'B ' '22' In another table where the column is CHAR(5), the values come back trimmed: 'CTDB' 'CTSUP' 'CT1A1' 'CT2B' 'CT3A' 'M1FH' 'M2CPH' 'M3FL' 'M4CPL' If I use the tooling in RAD(Eclipse) (which presumably just passes SQL to JDBC) to SQL such as: select concat(code,'.') from mytable; then for both tables, the values returned are always padded, eg 'CTDB .'. Assuming that values should always be padded to the column width, what can be causing the varying behavior? It is now apparent that this is not a JPA version issue. Could this be tied to how the data is stored in DB2? IOW, if 'CTDB' is inserted vs 'CTDB ', is this distinction 'lost' internally in DB2 by always padding before storing? Or as I could imagine, does the implementation always store fixed length fields as the actual data passed plus a length attribute (just like variable length) and only enforce the fixed lengthiness on fetch operations by padding it? The question matters, because if the former is true, then the question of how the data was inserted into one or the other tables could be completely ruled out, otherwise it could not (even though the driver behavior shown by executing SQL directly, would suggest it could). -- View this message in context: http://openjpa.208410.n2.nabble.com/Padding-of-CHAR-n-columns-with-trailing-spaces-tp6364510p6386498.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
