IBX 2.7.2, What's wrong with my codes?

[rvk]

No, I don't think there is an easy way to switch the default character set.
Even if it was possible, only newly created varchar fields would have that character set.
All others still have the character set from before.
So only with a dump and pump to new database would be possible to change it.

Now for the FPC experts... does a normal string type in FPC hold some kinda character set or encoding?? Can it be viewed? Because that's the only way I can think of that the .asString from IBX now will fill that and after that, concatenating with another string fails (when character set is none).

Internally there is something weird going on. I thought a string is a string... Hardcoded or assigned via .asString should matter. But here it does. So what could IBX have some to the string to behave like that??

[rvk]

Now for the FPC experts... does a normal string type in FPC hold some kinda character set or encoding?? Can it be viewed? Because that's the only way I can think of that the .asString from IBX now will fill that and after that, concatenating with another string fails (when character set is none).

BTW. Funny part is that this problem is only with IbSql.FieldByName(Fld).AsString
Using IbSql.FieldByName(Fld).AsAnsiString will work fine....

So there is definitely something with the string going on.

[dsiders]

Now for the FPC experts... does a normal string type in FPC hold some kinda character set or encoding?? Can it be viewed? Because that's the only way I can think of that the .asString from IBX now will fill that and after that, concatenating with another string fails (when character set is none).

BTW. Funny part is that this problem is only with IbSql.FieldByName(Fld).AsString
Using IbSql.FieldByName(Fld).AsAnsiString will work fine....

So there is definitely something with the string going on.

The only funny thing going on (IMHO) is that your dev environment needs to use the same string type as the database. Lazarus strings are UTF-8. If you don't want to manually do conversions, the database should use the same. YMMV.

[rvk]

The only funny thing going on (IMHO) is that your dev environment needs to use the same string type as the database. Lazarus strings are UTF-8. If you don't want to manually do conversions, the database should use the same. YMMV.

Normally, and this has been the case until IBX 2.7.2, you could just use TField.asString, regardless of the string type. Conversion was done automatically.

I even tried it with sqldb and there is absolutely no problem to use TField.asString, regardless of the database has NONE as character set.

Besides that... The strings dus really contain the text. This is shown in the debugger and it works when using it as single parameter or string.

Only when concatenating with another string or hardcoded string, things start to break

But I'm not sure why it's changed in IBX 2.7.2 (or why it still works in sqldb). Maybe that's something for @tonyw

[rvk]

FYI. This problem doesn't show in the trunk version of Lazarus/FPC (I just tested this).

Since my test project doesn't use LCL I suspect it's an incompatibility with older FPC 3.2.2 and latest IBX 2.7.2.