<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:1294839205.26572.56.camel@wsjoost.cnoc.lan"
 type="cite">
  <pre wrap="">
Didn't I explain this to you and others a few times?
  </pre>
</blockquote>
;-) If so, then please excuse me<br>
<br>
<blockquote cite="mid:1294839205.26572.56.camel@wsjoost.cnoc.lan"
 type="cite">
  <pre wrap="">
The database-components itself are encoding-agnostic. This means:
encoding in = encoding out.

So it is up to the developer what codepage he want to use. So
TField.Text can have the encoding _you_ want.

So, if you want to work with Lazarus, which uses UTF-8, you have to use
UTF-8 encoded strings in your database. 
  </pre>
</blockquote>
So this is answer, which i have looked for:<br>
"In Lazarus TStringField MUST hold UTF-8 encoded strings."<br>
<br>
But I guess (I have theory), that in time, when Borland introduced
TStringField, the design goal was:<br>
TStringField was designed for SBCS (because DataSize=Size+1) string
data encoded in system ANSI code page<br>
and<br>
TWideStringField was designed for DBCS widestring (UTF-16) character
data<br>
<br>
May be, that I was mistaken by this view.<br>
(or may be, that there is different approach in Delphi ("no agnostic")
and different in FPC ("agnostic")?)<br>
<br>
<blockquote cite="mid:1294839205.26572.56.camel@wsjoost.cnoc.lan"
 type="cite">
  <pre wrap="">If there is some strange reason why you don't want the strings in your
database to be UTF-8 encoded,</pre>
</blockquote>
SQL Server does not support UTF-8 (AFAIK)<br>
SQL Server provides non-UNICODE datatypes - char, varchar, text <br>
 and UNICODE (UCS-2) datatypes - nchar, nvarchar, ntext<br>
<br>
<blockquote cite="mid:1294839205.26572.56.camel@wsjoost.cnoc.lan"
 type="cite">
  <pre wrap=""> you have to convert the strings from the
encoding your database uses to UTF-8 while reading data from the
database.

Luckily, you can specify the encoding of strings you want to use for
most databases. Not only the encoding in which the strings are stored,
but also the encoding which has to be used when you send and retrieve
data from the database. And you can set this for each connection made.

Ie: you can resolve the problem by changing the connection-string, or by
adding some connection-parameter.

  </pre>
</blockquote>
Yes, it is true for example for MySQL or Firebird ODBC driver,<br>
 but for SQL Server or PostgreSQL ODBC driver there are no such options<br>
 (but PostgreSQL ODBC driver exists in ANSI and UNICODE version)<br>
 SQL Server ODBC driver supports "<span><span class="input">AutoTranslate</span>",
see: </span> <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/ms130822.aspx">http://msdn.microsoft.com/en-us/library/ms130822.aspx</a><br>
 "SQL Server <strong>char</strong>, <strong>varchar</strong>, or <strong>text</strong>
data sent to a client SQL_C_CHAR variable is converted from character
to Unicode using the server ACP, then converted from Unicode to
character using the client ACP."<br>
<blockquote cite="mid:1294839205.26572.56.camel@wsjoost.cnoc.lan"
 type="cite">
  <pre wrap="">There's also another solution you can find on the forum and other
places. You can convert the strings to UTF-8 not only when they are read
from the database, but also when they are read from the internal memory.
There's a hook for that.

  </pre>
</blockquote>
Thanks for your patience<br>
-Laco.<br>
<br>
</body>
</html>