wohlwissend, dass das hier wahrscheinlich der 1000ste Post dieser Art ist, ich trotz tagelanger Google- und welche-Foren-auch-immer-Recherche nach wie vor keinerlei brauchbare Lösungen gefunden habe und entsprechend mit den Nerven am Ende bin, wende ich mich einfach mal vertrauensvoll an die Experten hier!

Folgendes Problem:
Ich habe mir eine ODBC-Datenquelle (Benutzer-DSN) zu einer Access-DB (*.mdb) eingerichtet (Win7 64bit, die Geschichte mit der richtigen Treiberkonfig über ..\SYSWOW64\.. hab ich schon hinter mir^^).
In Lazarus erreiche ich diese nun über eine TODBCConnection, eine TSQLTransaction und eine TSQLQuery.
Funktioniert alles wunderbar, jedoch ist es wie so oft die Krux, dass meine German-Umlauts äöüß als ? dargestellt werden nach der Abfrage.
Meine Abfrage und Einstellung exemplarisch:
Code: Alles auswählen
ODBCConnection1.DatabaseName := 'TerminDummy';//ODBC-Datenbank
ODBCConnection1.Driver:='Microsoft Access Driver (*.mdb)';//Access-DB
ODBCConnection1.Params.Add('CHARSET=utf8');
ODBCConnection1.Transaction := SQLTransaction1;
SQLQuery1.DataBase:= ODBCConnection1;
SQLQuery1.UsePrimaryKeyAsKey := FALSE;
Date2Search := '25.04.2016';
SQLtext := 'SELECT * FROM termine WHERE Datum_Beginn LIKE '''+Date2Search+'%''';
SQLQuery1.SQL.text := SQLtext;
SQLQuery1.Open;
Code: Alles auswählen
ODBCConnection1.Params.Add('CHARSET=utf8');
Auch ein Eintrag in einer ODBC.ini (anliegend im WINDOWS-Ordner) von wegen
Code: Alles auswählen
charset=utf8
Der Versuch, die Connection direkt über dieses ODBC-Admin-Tool irgendwie zu konfigurieren.... Keine Ahnung, wie das funktionieren soll.
Mir werden folgende Möglichkeiten geboten, Variablen zu füllen:
DefaultDir
Driver
ExtendedAnsiSQL
FIL
ImplicitCommitSync
MaxBufferSize
MaxScanRows
PageTimeout
ReadOnly
SafeTransactions
Threads
UserCommitSync....
jedoch kein Charset oder dgl.
Ich schätze, es liegt überhaupt nicht an der AnsiToUtf8-Geschichte in Lazarus, sondern an der Datenquelle bzw. der Abfrage selber...
Auf diese Idee komme ich, wenn ich mir bei dem ODBC-Admin-Tool mal die Ablaufverfolgung aktiviere, in meinem SQL-Log so etwas finde wie
Code: Alles auswählen
ODBCTest bf4-1110 ENTER SQLGetData
HSTMT 0x0000000001459920
UWORD 2
SWORD 1 <SQL_C_CHAR>
PTR 0x0000000001225B45
SQLLEN 21
SQLLEN * 0x000000000102F4A8
ODBCTest bf4-1110 EXIT SQLGetData with return code 0 (SQL_SUCCESS)
HSTMT 0x0000000001459920
UWORD 2
SWORD 1 <SQL_C_CHAR>
PTR 0x0000000001225B45 [ 7] "sch\fffer"
SQLLEN 21
SQLLEN * 0x000000000102F4A8 (7)
Es scheint ggf an der Abfrage zu liegen, jedoch hilft mir der Super-MS-Info-Bla zu ODBC nicht wirklich etwas...
Es scheint eine eigene Art von SQL-Platt zu sein, das weder mit CONVERT- oder CAST-Funktion etwas anfangen kann....
Code: Alles auswählen
SELECT * FROM Termine WHERE {fn CONVERT(Name,SQL_CHAR)} LIKE '1%'
Egal ob mit oder ohne {fn...}, die Fehlermeldung bleibt
Code: Alles auswählen
Could not prepare statemend. ODBC error details: LastReturnCode: SQL_ERROR; Record 1: SqlState: 42000; NativeError: -3513; Message: [Microschrott][ODBC-Treiber f?r Microschrott Access] Syntaxfehler in WHERE-Klausel.;
Code: Alles auswählen
...NativeError: -3102; Message: [Microschrott][ODBC-Treiber f?r Microschrott Access] Undefinierte Funktion 'CONVERT' in Ausdruck.;
Mein ODBC-Treiber hat die Version 14.00.7010.1000 (ACEODBC.DLL), falls es hilft.
Hat bittebittebitte jemand eine Idee, woran das liegen kann und welchen Parameter man wie einstellen könnte, um an diese *$&%(§"§$% Umlaute zu kommen?
Vielen Dank!!
EDIT: Schade, dass niemand eine Idee hat

Das Problem besteht nach wie vor, jedoch habe ich herausgefunden, dass beim Speichern der Strings in eine Datei plötzlich wie von Zauberhand alle Umlaute wieder da sind....
Dann liegt es ja vielleicht doch an der AnsiToUtf8-Geschichte.... Wie auch immer.. danke!