| Subject | Re: [IBO] IBO - IB_String vs AnsiString |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-04-09T07:00:23Z |
At 04:10 PM 9/04/2009, m. Th. wrote:
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()).
As I don't have Delphi 2009, I have to confess I've no idea what has been done there that seems to create a new problem w.r.t. character sets....so, in essence, I really can't grokk what this thread is all about.
Helen
>Jason Wharton wrote: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.
>>> So, I haven't looked at the new IBO yet, but is a "sql statement" now
>>> fully unicode? Or AnsiString?
>>>
>>
>> The API doesn't appear to allow unicode strings yet. If it does I am not
>> aware of it.
>> My guess is they will have new API calls that are unicode compliant rather
>> than making the existing AnsiString based calls switch over.
>>
>> Jason
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()).
As I don't have Delphi 2009, I have to confess I've no idea what has been done there that seems to create a new problem w.r.t. character sets....so, in essence, I really can't grokk what this thread is all about.
Helen