Andreas Hesse wrote:

> m. Th. schrieb:
>
>> Andreas Hesse wrote:
>>
>> <snip>
>> Take care here!!
>>
>> This was a very big discussion 'somewhere' :-). I cannot tell you many
>> things but due of compatibility reasons - mainly concerns which are tied
>> to the fact that many users are storing non-text data (binary etc.)
>> using .AsString - the Get/SetAsString uses GetAsAnsiString internally.
>>
>
> Strings for storing Bytes is and was always bad design.
> The only reason for this was, because AnsiString is Referece-counted.
> But with D2009 it is a very bad design.
>

Yes, of course. FTR, we don't use it (IIRC). But 'somewhere' there were
some polls which showed that approx. 60% of users would be hit if the
.AsString would returning an Unicode string. As an aside, another reason
to use them was the ease of use. Ie. a simple .AsString compared to
binary access to a stream which must be created, read/write, destroyed
etc.. I didn't say that it was/is a good practice I said that it is/was
a (rather) _common_ practice.

Do we have the above situations in our code? (Ie. if someone has it
raise the hand).

>
>> From D2009's DB.PAS:
>>
>> function TStringField.GetAsString: string;
>> begin
>> Result := string(GetAsAnsiString);
>> end;
>>
>
> AsString returns a string (=UnicodeString)
>

Nope. Even if AsString returns a string which is UnicodeString (which is
good), the internal call to GetAsAnsiString returns an AnsiString so the
smallest denominator is AnsiString.

>
>> ....also you can have a look at TStringField.GetValue(var Value:
>> AnsiString): boolean;
>> and, of course at SetAsString.
>>
>>
>
> TStringField is really a TAnsiStringField.
> So for using Unicode within DB-Layer we must use TWideStringField.
>
>
>> The workaround (for the time being) is to use .AsWideString which
>> returns an Unicode string.
>>
>
> No, it returns only a Unicoded AnsiString for TStringField.
> see above, using TWideStringField is the only possibility.
>
>

Yes.

>> Also, since the above hard-cast is in DB.Pas (iow outside of our
>> control) there will be problems with TIBO layer.
>>
>
> No, Text Fields should be now created as TWideStringField's (if they are
> created dynamically).
> But I don't check the source for it.
>
> The native TIB_Column does not differ between AnsiString and WideString
> Column. It only differ between Fixed Text (Char) and Variable Text
> (VarChar) columns.
> And if it is a AnsiString or a WideString Field depends on the
> connection charset.
>
>

Yes, but I speak more from TIBO layer POV which I use.


m. Th.


[Non-text portions of this message have been removed]