TODBCConnection Access Violation

[KOBOLD Messring GmbH]

Hola,
wollte (anstelle von Zeos TZConnection) nun zum erstenmal TODBCConnection verwenden.
Die neue Zeos Ver. 7 funktioniert nicht richtig (kann immer nur einmal eine Query öffnen. Beim nächsten Mal (natürlich nach ordentlichem ZQuery1.Close schmiert die Anwendung ab .
Deshalb wollte ich nun die Lazarus-interne TODBCConnection verwenden. Habe linuxODBC installiert, DSN eingerichtet, geht auch alles, aber mit der TODBCConnection (Lazarus 0.9.26 beta vom 10.9.2008) bekomme ich nur "Access Violation" wenn ich versuche im ObjectInspector die ODBCConnection auf Connected:=true zu setzen.
¿wie muss ich denn die TODBCConnection konfigurieren?
¿was mach ich falsch?
¿Kann jemand helfen? Habe hier im Forum nichts gefunden.
Hintergrund ist, dass ich eine Anwendung schreibe, die sowohl unter Linux auf MySQL (geht hervorragend mit "alter" Zeos 6.6 TZConnection und "neuer" Lazarus TMySQLConnection) als auch unter Windows auf MS-Access zugreifen muss.
Also dachte ich ODBC ist die Lösung, denn das kann ja alles, wenn die Treiber da sind.
Aber ich bin im Moment an der TODBCConnection gescheitert.
¡Bitte Hilfe!

[EugenE]

bei TOBDCConnection.DataBaseName den DSN Namen namen, falls noch ein Passwort benötigt wird dieses bei .Password auch noch setzen

falls das nicht funktioniert wäre ein Backtrace ganz nett , da ich in letzter zeit sehr viel mit ODBCConnection gearbeitet habe als auch eine verbessterte für meinen SQL-Editor geschrieben habe , denke ich schon das ich dabei helfen kann^^

[KOBOLD Messring GmbH]

Vielen Dank,
habe die TODBCConnection jetzt unter WindowsXP ausprobiert, funktioniert, aber dann macht die TQuery zicken, SQL-Error, cannot get metadata.
Tja, habe im Forum-Beitrag "Re: MS Access zugriff - letzter Thread!" gelesen, dass man für MS-Access (also die Jet-DB) besser ADO benutzt, ¿wie mach ich denn das unter Lazarus?
Und am allerallerallerliebsten hätte ich ja schon, dass man auch unter Linux auf so'ne Jet-DB (mdb) zugreifen könnte.
(ohne für 699 EUR !!! den ODBC-ODBC-Bridge-Client-Server von Easysoft kaufen zu müssen)

[EugenE]

TQuery.UsePrimaryKeyAsKey := false;

dann müsste es gehen

[KOBOLD Messring GmbH]

Vielen Dank EugenE
werde das gleich ausprobieren mit. Auch unter Linux bin ich einen Schritt weiter. Anstelle direkt im ObjectInspector die ODBCConnection auf True zu setzen (was immer nur Access Violation brachte) kam ich auf die Idee, das im laufenden Programm zu machen, und schon kam eine aussagekräftige Meldung: cannot load libodbc.so
Seltsam, bei mir hatte sich eine libodbc.so.1 installiert (von dem unixODBC Paket). Ein Link drauf unter obigem Namen schon geht's.

[KOBOLD Messring GmbH]

Nochmals vielen Dank
TQuery.UsePrimaryKeyAsKey := false; im FormCreate gesetzt und funktioniert.
ABER habe noch mehr Probleme:
1.) Der Zeichensatz: ALLE strings (TStringField wird korrekt gesetzt) erscheinen sehr "chinesisch", habe überall "latin1" als CharSet eingestellt (bei TODBCConnection und unter Linux auch im ODBC-Data-Source-Administrator) aber das Resultat ist vernichtend... nicht nur bei Sonderzeichen sondern ALLE Buchstaben sind chinesisch (oder Thai, oder ...).
¿Muss ich da irgendwelche Konvertierungen machen? ¿Gibt es da schon Erfahrungen?
2.) Noch schlimmer: wenn ich versuche die Query mehrmals zu schliessen und zu öffnen, schmierts ab mit:
ntdll!RtlEnumerateGenericTableLikeADirectory
im SQL-Trace-log steht aber immer nur "SQLAllocHandle with return code 0 (SQL_SUCCESS)"
(ist ja auch successfully abgeschmiert

Für Jet-DB (MS-Access) soll man die ADO verwenden habe ich hier gelesen
¿Kannst Du mir helfen (gibt's da ein Tutorial oder so)?
Vielen Dank schon mal im Voraus

[EugenE]

es gibt keine ADO-Komponente für Lazarus ... leider

zu 1) das habe ich noch nicht gesehen ist das unter Windows oder Linux der fall? vllt hilft das http://bugs.freepascal.org/view.php?id=12206" onclick="window.open(this.href);return false;
vllt kann man auch als Parameter das hier helfen "CHARSET=UTF8" zu mindest bei den meisten Datenbank-Typen hat es bei mir geholfen
zu 2) etwas genauer, welcher Query auf welche Datenbank Engine, welche Tabelle mit welchen Spalten-Typen etc^^ vllt finden wir auch da noch ne Lösung ^^

[KOBOLD Messring GmbH]

Hola Eugen,
zu beiden Fragen: passiert sowohl unter Linux (Mandriva 2008, Lazarus 0.9.26) als auch Windows (XP, gleiche Lazarus),
zu 1) Windows zeigt Fragezeichen an, Linux eben die chinesischen Zeichen, siehe Screenshots.
Danke für den Link, aber die Funktionen AnsiToUTF8 und umgekehrt bringen gar nichts, habe das Gefühl, die machen auch überhaupt nichts.
Habe beim ODBC-Manager und bei der ODBCConnection alle Kombinationen ausprobiert (latin1, utf8 und vice versa), aber immer das gleiche.
Zu 2) Unter Windows ist das eine MS-Access-Jet-DB, Version 2000, kann ich mit Access2000 ohne Probleme öffnen, besteht nur aus einigen String-Feldern (varchar 50), int und float.
Unter Linux das gleiche in MySQL. Geht perfekt wenn ich mit ZeosDB oder auch direkt mit SQLDb-Komponenten drauf zugreife, aber mit ODBC nix zu wollen.
¿Eine Idee?

[EugenE]

ich glaube das hat trotzdem was mit dem UTF8 Codes zu tun, vllt anstatt bei den Eigenschaften CHARSET=UTF8 zu nehmen lieben CHARSET=UTF8 bei den Params zu schreiben also mit Params.Add('CHARSET....

falls das immernoch nicht hilft wäre es wohl dringend notwendig dies als Bug zu melden

[KOBOLD Messring GmbH]

Du hast Recht, es MUSS daran liegen. Ich hab auch was herausgefunden:
Ich habe mal per gleichem ODBC ein SQL-UPDATE-Statement gemacht,
wenn ich nur einen Buchstaben eintrage, ¡¡IST ES KORREKT !!
Sobald ich mehr eintrage, werden jeweils zwei Bytes zu einem "Char" zusammengefasst. Wird eine ungerade Anzahl eingetragen, wird - in dieser Logik korrekt - nur der letzte Buchstabe korrekt angezeigt.
Siehe Screenshot: ich habe `AAA` eingetragen, also $4141 gibt es wohl auch im "chinesischen" Zeichensatz nicht, deshalb zeigt er EIN (1 nicht 2) Kästchen mit den ASCII-Codes numerisch (mit der Bildschirmlupe erkennt man 41 41) das sind zweimal hexadezimal von ASCII 65, also 2 grosse A, die - mit Gewalt - zu einem Buchstaben zusammengefasst werden.
Darauf kann man doch aufbauen ¿Sind das nicht die berühmten WideString?
Delphi-Basics.co.uk sagt: "Each character is a WideChar, guaranteed to be 16 bits in size"
An dieser Stelle werde ich ein bisschen Basteln.
Es gibt doch auch dafür Konvertierungsroutinen z.B von theo aus dem Forum hier, Thema "Lazarus charset - Umlaute"
function LongStringToWideString(const S: AnsiString): WideString;
(Ich fürchte aber, ich brauch die Umkehrung, denn WideString ist es ja anscheinend, werde also suchen müssen)
Obige Funktion funktioniert perfekt für die GTK2 TMemo und TCombo und Verwandte, aber dieses Pointer-Bit-Geschiebe finde ich ehrlich gesagt sehr verwirrend...

[theo]

Darauf kann man doch aufbauen ¿Sind das nicht die berühmten WideString?
Delphi-Basics.co.uk sagt: "Each character is a WideChar, guaranteed to be 16 bits in size"
An dieser Stelle werde ich ein bisschen Basteln.
Es gibt doch auch dafür Konvertierungsroutinen z.B von theo aus dem Forum hier, Thema "Lazarus charset - Umlaute"
function LongStringToWideString(const S: AnsiString): WideString;

Lazarus arbeitet mit UTF-8, also nicht Widestrings!! Vergiss die.
Ich verstehe zwar nichts von Lazarus DB, aber wenn die DB auch mit UTF-8 arbeitet und sonst auch alles so eingestellt ist, sollte es keine Probleme geben.

[mse]

Darauf kann man doch aufbauen ¿Sind das nicht die berühmten WideString?

Welchen Typ haben denn die Textfelder in der Originaldatenbank?
Ich habe letzthin Support für SQL_WCHAR entsprechend ftFixedWideChar, ftWideString und ftWideMemo in tmseodbconnection eingebaut. Die Ergänzungen sind in Version 2.0beta1 enthalten.
Ansonsten würde ich empfehlen, mal mit dem Debugger die Vorgänge in TODBCConnection.LoadField und TODBCConnection.SetParameters zu beobachten.

Martin

[KOBOLD Messring GmbH]

Vielen Dank Martin,
am Typ von den Fields muss es liegen. Beim Hinzufügen der Felder (in der IDE, Feldeditor) werden diese automatisch als TWideStringField angelegt, ABER bei der Konvertierung mangelt es offensichtlich: Egal ob man den Wert mit AsString oder mit AsWideString ausliest, es bleibt bei "Chinesisch".
Ich habe jetzt einen Workaround gemacht:

Code: Alles auswählen

Procedure Tform1.SQLQuery1GetText (Sender : Tfield; Var Atext : String; Displaytext : Boolean );
VAR sOri : WideString;
    sNeu : String;
    w    : WideChar;
    ZweiChars : Array [0..1] OF Char ABSOLUTE w;
    i    : Integer;
Begin
  sOri  := Sender.AsWideString;
  sNeu := '';
  FOR i := 1 TO Length (sOri) DO
   Begin
     w := sOri [i];
     sNeu := sNeu + ZweiChars [0] + ZweiChars [1];
   End; { For i, alle Buchstaben im String }
  AText := sNeu;
End; { GetText}

Und diese Funktion allen (Wide)StringFields al OnGetText zugewiesen.
Sicherlich nicht sehr elegant (Byte-Geschiebe), aber funktioniert.
Mit der internen Funktion WideCharToString funktioniert es leider nicht.
Wie man am Screenshot sieht, ist die Zeichenkodierung korrekt mit UTF8, weshalb man auch keine weiteren Massnahmen mehr braucht, also egal ob ein Buchstabe 1 oder mehr Bytes braucht, die Funktion Length weiss anscheinend nichts von UTF8 und gibt einfach die Zahl der WideChars wieder (egal ob hier z.B. ein Ä als $84C3 also mit 2 WideChars kodiert ist).
Das Steuerelement (das TDBGrid oder das TLabel) interpretiert es dann korrekt.
¿¿Wie sag ich denn dem FeldEditor, dass er einen bestimmten Feldtyp nehmen soll?? Beim Hinzufügen der Felder geschieht dies doch automatisch und dann ist es doch "zu spät".
¿ Hast Du Diese Klasse gemacht: tmseodbconnection? ¿Kann man die woher bekommen, darf man die benutzen?

[mse]

¿ Hast Du Diese Klasse gemacht: tmseodbconnection? ¿Kann man die woher bekommen, darf man die benutzen?

Auf die Gefahr hin, dass ich gleich eins aufs Dach bekomme, aber es ist schon schmerzhaft zu sehen, wie sich die Lazarus Nutzer abplagen müssen:
tmseodbcconnection ist Teil von MSEide+MSEgui worüber hier ein eigenes Unterforum existiert. MSEgui arbeitet intern komplett mit widestring so dass in der Regel keine Probleme, wie du sie erlebt hast, auftreten dürften. Bitte stelle allfällige Fragen in NNTP:
[url]news://news.grid-sky.com/public.mseide-msegui.talk[/url]
oder hier im MSEide+MSEgui Unterforum.

Martin

[theo]

Beim Hinzufügen der Felder (in der IDE, Feldeditor) werden diese automatisch als TWideStringField angelegt,

Waurm macht er das? Ich würde sagen, das Problem ist hier zu suchen. Eigentlich sollte hier doch WideString gar nicht ins Spiel kommen.