Tweet
Liebe Delphi-Gemeinde,<p>
ein frohes neues Jahr!<br><br>
Ich greife mit <font color=olive>ADO</font> auf unterschiedliche Datenquellen zu. Der Anwender kann wählen zwischen <i>mdb</i>, <i>xls</i>, <i>dbf</i> und <i>txt</i> im CSV-Format (das Programm dient der Fremddatenübernahme).<br>
Nach bestimmten Kriterien werden die Daten überprüft, aufbereitet und in eine <i>mdb</i> feststehender Struktur importiert. Das klappt soweit hervorragend.<p>
Bei der Erweiterung des Programms auf <font color=olive>ODBC</font>-Datenquellen lese ich die ODBC-Angaben aus der Registry oder <i>dsn</i>-Dateien aus und baue sie in den Connectionstring ein. Auch das funktioniert. Die Daten können angezeigt und ausgelesen werden. Tests liefen mit DB2-, Oracle- oder MSSQL-Datenbanken reibungslos.
Doch bei den Datenprüfungen und -aufbereitungen trat ein Problem auf: Sobald bestimmte Funktionen (Len, iif, val) oder Stringoperationen verwendet werden (Strings mit & aneinanderfügen), funktionieren die entsprechenden SQL-Abfragen nicht.<br><br>
Das ist eigentlich sogar ganz logisch, denn bei der ADO-Technik übernimmt nicht der ODBC-Treiber die Anpassung der SQL-Syntax, sondern ADO schleust diese direkt auf die Datenquelle durch. Damit ist man vom SQL-Dialekt der Datenquelle abhängig (+ oder || statt &, 0 statt false, sysdate oder getdate oder now, usw.).<br><br>
Also dachte ich so bei mir, verzichte doch in diesen wenigen, aber entscheidenden Fällen auf ADO, nimm die Objekte TDataset und TQuery. Problem gelöst.<br>
Doch leider haben diese Objekte gar keine Eigenschaft <font color=olive>Connectionstring</font>. Stattdessen gibt es TQuery.Database, doch die erwartet offenbar direkt eine Datenbank, denn dsn-Dateien werden nicht akzeptiert. Und wenn ich Benutzer- oder Systemdatenquellen verwende, habe ich nur die in der Registry eingetragenen Verbindungsdaten zur Verfügung und gar keine Datei, die ich der Eigenschaft Database geben könnte.<br><br>
Dann gibt es noch TQuery.Datasource, die auf ein TDatasource verweist. Dazu brauche ich dann aber TDatasource.Dataset, die auf ein TDataset verweist. Die wiederum hat TDataset.Datasource. Hier drehe ich mich im Kreis, bin auch auf dem Gebiet nicht so beschlagen, denn ich habe bisher immer mit ADO gearbeitet, Connectionstring und fertig.<br><br>
Die Frage also ist:
<font color=green><ul>Wie kann ich mich mit beliebigen ODBC-Datenbanken verbinden und den ODBC-Treiber die SQL-Syntax interpretieren lassen? </ul>
<ul>Wenn es wirklich nicht mit ADO geht, wie bringe ich den normalen Delphi-Objekten die ODBC-Verbindung bei?</ul>
<ul>Gibt es noch weitere Möglichkeiten (DAO, RDO, OLEDB)?</ul></font>
<br>Wer weiß Rat?<p>
mfg Alex
ein frohes neues Jahr!<br><br>
Ich greife mit <font color=olive>ADO</font> auf unterschiedliche Datenquellen zu. Der Anwender kann wählen zwischen <i>mdb</i>, <i>xls</i>, <i>dbf</i> und <i>txt</i> im CSV-Format (das Programm dient der Fremddatenübernahme).<br>
Nach bestimmten Kriterien werden die Daten überprüft, aufbereitet und in eine <i>mdb</i> feststehender Struktur importiert. Das klappt soweit hervorragend.<p>
Bei der Erweiterung des Programms auf <font color=olive>ODBC</font>-Datenquellen lese ich die ODBC-Angaben aus der Registry oder <i>dsn</i>-Dateien aus und baue sie in den Connectionstring ein. Auch das funktioniert. Die Daten können angezeigt und ausgelesen werden. Tests liefen mit DB2-, Oracle- oder MSSQL-Datenbanken reibungslos.
Doch bei den Datenprüfungen und -aufbereitungen trat ein Problem auf: Sobald bestimmte Funktionen (Len, iif, val) oder Stringoperationen verwendet werden (Strings mit & aneinanderfügen), funktionieren die entsprechenden SQL-Abfragen nicht.<br><br>
Das ist eigentlich sogar ganz logisch, denn bei der ADO-Technik übernimmt nicht der ODBC-Treiber die Anpassung der SQL-Syntax, sondern ADO schleust diese direkt auf die Datenquelle durch. Damit ist man vom SQL-Dialekt der Datenquelle abhängig (+ oder || statt &, 0 statt false, sysdate oder getdate oder now, usw.).<br><br>
Also dachte ich so bei mir, verzichte doch in diesen wenigen, aber entscheidenden Fällen auf ADO, nimm die Objekte TDataset und TQuery. Problem gelöst.<br>
Doch leider haben diese Objekte gar keine Eigenschaft <font color=olive>Connectionstring</font>. Stattdessen gibt es TQuery.Database, doch die erwartet offenbar direkt eine Datenbank, denn dsn-Dateien werden nicht akzeptiert. Und wenn ich Benutzer- oder Systemdatenquellen verwende, habe ich nur die in der Registry eingetragenen Verbindungsdaten zur Verfügung und gar keine Datei, die ich der Eigenschaft Database geben könnte.<br><br>
Dann gibt es noch TQuery.Datasource, die auf ein TDatasource verweist. Dazu brauche ich dann aber TDatasource.Dataset, die auf ein TDataset verweist. Die wiederum hat TDataset.Datasource. Hier drehe ich mich im Kreis, bin auch auf dem Gebiet nicht so beschlagen, denn ich habe bisher immer mit ADO gearbeitet, Connectionstring und fertig.<br><br>
Die Frage also ist:
<font color=green><ul>Wie kann ich mich mit beliebigen ODBC-Datenbanken verbinden und den ODBC-Treiber die SQL-Syntax interpretieren lassen? </ul>
<ul>Wenn es wirklich nicht mit ADO geht, wie bringe ich den normalen Delphi-Objekten die ODBC-Verbindung bei?</ul>
<ul>Gibt es noch weitere Möglichkeiten (DAO, RDO, OLEDB)?</ul></font>
<br>Wer weiß Rat?<p>
mfg Alex
, aber da der Funktionsumfang vorher nicht bekannt ist, werde ich hier vermutlich die nicht unterstützten Funktionen simulieren müssen. D.h. ich zeige mir die Daten ohne Benutzung zweifelhafter Funktionen an und lasse ein Delphiprogramm die Analyse des Recordsets durchführen. Geht garantiert, ist nur leider möglicherweise wesentlich langsamer. Das werden Erfahrungen zeigen.
Comment