| Subject | Problem with TMemoField and ISO8859_1 charset blob field in RAD Studio XE / IBX |
|---|---|
| Author | ipai1 |
| Post date | 2010-12-21T21:43:48Z |
G'day all...
I have been having fun porting a Delphi application from BDS2006 (no unicode) to RAD Studio XE (unicode as default) with the corresponding shipped version of IBX.
The Firebird database and client library is version 2.5 but the problem also occurs with 2.1. I am thinking it might be an IBX issue, but I thought I'd start here.
The field causing the problem is defined as "BLOB SUB_TYPE 1 SEGMENT SIZE 80" with ISO8859_1 charset and collation. The corresponding dynamic field created in the Delphi dataset is a TMemoField, but when I try to access the MemoField.AsString (or MemoField.AsText) property, the string returned has a null in every second character. It looks to me like the non-unicode charset is being incorrectly treated as unicode.
I have worked around the problem for the moment by processing the string to remove every second (null) character, but I'd prefer to get the right result in the first place. Has anyone else encountered this problem?
Thanks in anticipation,
Alex.
I have been having fun porting a Delphi application from BDS2006 (no unicode) to RAD Studio XE (unicode as default) with the corresponding shipped version of IBX.
The Firebird database and client library is version 2.5 but the problem also occurs with 2.1. I am thinking it might be an IBX issue, but I thought I'd start here.
The field causing the problem is defined as "BLOB SUB_TYPE 1 SEGMENT SIZE 80" with ISO8859_1 charset and collation. The corresponding dynamic field created in the Delphi dataset is a TMemoField, but when I try to access the MemoField.AsString (or MemoField.AsText) property, the string returned has a null in every second character. It looks to me like the non-unicode charset is being incorrectly treated as unicode.
I have worked around the problem for the moment by processing the string to remove every second (null) character, but I'd prefer to get the right result in the first place. Has anyone else encountered this problem?
Thanks in anticipation,
Alex.