Subject | Re: [IBO] IBO - IB_String vs AnsiString |
---|---|
Author | m. Th. |
Post date | 2009-04-09T08:36:18Z |
Helen Borrie wrote:
Select * from t1 where f1 = 'αᾶὰἀᾲᾄᾳᾆ'; /* Unicode characters. I hope
that my newsreader will save them correctly */
...and after this we can read the data from that field (which ISN'T a
BLOB one) using the TField descendants, assuming that we use the TIBO layer?
...or we can use the myIBODataSet.Filter property
...or Set/GetSQLWhere?
Can you expand a bit?
> When I saw Jason's reply, I assumed he was talking about the Windows API. If you're both actually talking about the *Firebird* API then there's never been a suggestion that *SQL statements* would be in any flavour of Unicode.Do you mean that in D2007 we can issue and use queries like
>
> As for passing arguments in DML, the API and the engine take care of it, provided the application environment is appropriately set up. That is, if the code page that the user is using is compatible with the code page that applies to the character set expected for inputs to columns and params of CHAR() and VARCHAR(), it "just works". If, in passing extraneous character data to your SQL parameters, you have incompatibilities, then the same provisions as always are available to you in your SQL...including the ability to do explicit casts and to force IBO to pass "raw" SQL to the API.
>
> IBO does (and always did) support the default database character set at the client connection (isc_dpb_lc_ctype parameter of isc_attach_database()).
>
>
Select * from t1 where f1 = 'αᾶὰἀᾲᾄᾳᾆ'; /* Unicode characters. I hope
that my newsreader will save them correctly */
...and after this we can read the data from that field (which ISN'T a
BLOB one) using the TField descendants, assuming that we use the TIBO layer?
...or we can use the myIBODataSet.Filter property
...or Set/GetSQLWhere?
Can you expand a bit?