ADO und Interbase

[Patrick Sack]

<br>Hi,...
<br>
<br>(Delphi5 SP1, InterBase 5.6.0.29, Intersolve InterBase ODBC Driver IBINT13.Dll Version 03.11.1000)
<br>
<br>Ich bekomme bei einem Post-Befehl mit CursorLocation=clUseClient die folgende Fehlermeldung:
<br>"Der Datenprovider oder ein anderer Dienst gab den Status E_Fail zurück."
<br>
<br>Wenn clUseClient auf clUseServer geändert wird und das AdoDataSet nicht in Verbindung mit einem TDataSource Element ist, so wird das Insert ausgeführt.
Ist jedoch das AdoDataSet mit einem TDataSource Element verbunden, so erscheint beim Insert-Befehl der folgende Fehler:
<br>"Die Datenmenge unterstützt keine Positionsmarken, die von Multi-Datensatz-Elementen benötigt werden."
<br>
<br>Welche CursorLocation sollte man bei dem Interbase verwenden? clUseClient vermute ich oder?
<br>
<br>.
<br>.
<br>.
<br> Funktionen.ExecSQLCommand(
<br> 'CREATE TABLE Best_Temp ' +
<br> '( ' +
<br> 'ABG_ArtNr VARCHAR(6) NOT NULL, ' +
<br> 'WG VARCHAR(6), ' +
<br> 'ABG_ID Integer, ' +
<br> 'LFT_ID Integer, ' +
<br> 'ALFT_ID Integer, ' +
<br> 'LFT_Kurz VARCHAR(6), ' +
<br> 'ARTNR_LFT VARCHAR(100), ' +
<br> 'EAN_CODE VARCHAR(13), ' +
<br> 'ABG_ArtKuFo VARCHAR(30), ' +
<br> 'ABG_BEZ VARCHAR(100), ' +
<br> 'ALFT_PREIS Float, ' +
<br> 'PREIS_BASIS Integer, ' +
<br> 'SUMME Float, ' +
<br> 'ANZAHL Float, ' +
<br> 'LIEFWOCHE Integer, ' +
<br> 'PRIMARY KEY (ABG_ArtNr) ' +
<br> ');');
<br>
<br> qrytblBest_Temp.Open;
<br> qrytblBest_Temp.Insert;
<br> qrytblBest_Temp.FieldByName('ABG_ArtNr').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('WG').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('ABG_ID').asInteger := 0;
<br> qrytblBest_Temp.FieldByName('LFT_ID').asInteger := 0;
<br> qrytblBest_Temp.FieldByName('ALFT_ID').asInteger := 0;
<br> qrytblBest_Temp.FieldByName('LFT_Kurz').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('ARTNR_LFT').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('EAN_CODE').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('ABG_ArtKuFo').asStrin g := 'Test';
<br> qrytblBest_Temp.FieldByName('ABG_BEZ').asString := 'Test';
<br> qrytblBest_Temp.FieldByName('ALFT_PREIS').asFloat := 0;
<br> qrytblBest_Temp.FieldByName('PREIS_BASIS').asInteg er := 0;
<br> qrytblBest_Temp.FieldByName('SUMME').asFloat := 0;
<br> qrytblBest_Temp.FieldByName('ANZAHL').asFloat := 0;
<br> qrytblBest_Temp.FieldByName('LIEFWOCHE').asInteger := 0;
<br> qrytblBest_Temp.Post;
<br>.
<br>.
<br>.
<br>Wenn ich das Insert mit dem SQL-Befehl INSERT mache, so kann ich Daten einfügen. Nur ich würde natürlich lieber den obigen Code verwenden.
<br>
<br>Ich bin etwas frustriert, da ich solchen Code schon erfolgreich bei Access oder SQL Server angewendet habe.
<br>Bin dankbar für jede Hilfe.
<br>
<br>MfG
<br>PS

[Andreas Kosch]

Hallo,

in dem o.g. Fall greift ADO über den OLE DB Provider für ODBC-Treiber auf den ODBC-Treiber zu. Somit bestimmt in der Aufrufkette <i>ADO Express -> ADO -> OLE DB Provider für ODBC -> ODBC -> InterBase-API -> InterBase</i> das schwächste Glied das Gesamtverhalten.

Wenn <b>clUseClient</b> und somit das RecordSet-Objekt verwendet wird, kann man keinen Datensatz auf diesem Weg neu anlegen/ändern. Wenn <b>clServer</B> verwendet wird, ist das lokale RecordSet-Objekt nicht beteiligt, die SQLs gehen direkt an die InterBase-Datenbank. Ein Post/Delete ist möglich, allerdings mit Nebenwirkungen: <br>
a) kein DBGrid <br>
b) nur ctOpenForwardOnly -> kein Rückwärts-Browsen in der Ergebnismenge

Normalerweise würde man in der Dokumentation des Treibers nachsehen, welche Laufzeit-Properties für das RecordSet-Objekt gesetzt werden können. Während Microsoft diese Parameter für die eigenen Treiber vorbildlich ausführlich dokumentiert, habe ich zum ODBC-Treiber für den InterBase noch nichts derartiges gefunden. Somit hat man nur 2 Möglichkeiten: <br>
1. Völliger Verzicht auf InterBase-Datenbanken <br>
2. Einschränkungen akzeptieren und eigenes Programmdesign anpasse

[Patrick Sack]

<br>Danke!
<br>
<br>was ist mit "...eigenes Programmdesign anpssen" gemeint?
<br>Sollte man die Interbase Komponenten verwenden?
<br>
<br>Wir wollen unsere Software eigentlich datenbankneutral programmieren. Auf den ersten Blick hatte ich vermutet so etwas mit ADO erstellen zu können. Aber anscheinend ist ADO doch zu sehr auf Microsoft eingerichtet.
<br>Gibt es noch eine andere Möglichkeit datenbankunabhängige Programme zu schriben? (im db-server Bereich)
<br>
<br>
<br>MfG
<br>P

[Andreas Kosch]

Hallo,

mit "..Programmdesign anpassen.." habe ich nicht die Komponenten-Typen gemeint, sondern den prinzipiellen Aufbau der Anwendung. Wenn man auf ein editierbares TDBGrid verzichtet (was in einer C/S generell sinnvoll ist) und die Lese- und Schreibzugriffe über Stored Procedures (TADOStoredProc) laufen lässt, spielen die Einschränkungen des InterBase-ODBC-Treibers sowie von ADO Express keine Rolle - hier ist <b>nicht</b> Microsoft der Schuldige ;-)

Wenn man auf die Hilfe des <b>MSDataShape</b>-Providers zurückgreift, kann man im eigenen Programm In-Memory-Tabellen verwenden, die von Delphi und ADO als vollwerte Datenquellen betrachtet werden, obwohl <b>keine</b> Datenbankverbindung dahinter hängt. Somit kann man auch ein TDBGrid an diese "Tabellen" hängen (die auf dem anderen Weg mit Daten gefüllt werden)

[Patrick Sack]

<br>@A.Kosch:
<br>wenn ich noch mal stören darf,...
<br>
<br>das Programm lief zuvor unter der BDE einwandfrei mit dem Code. Heißt das, wenn ich Programme die mit der BDE erstellt wurden umsetzen will auf ADO, <b>ohne viel umzustellen</b>, daß man dann als Backend besser nicht den Interbase nutzen sollte?
<br>Anmerkung:
<br>Ich habe schon andere Programme umgestellt z.B. auf den SQL Server und habe dort nicht dieses Problem gehabt (aber andere ;-)).
<br>
<br>
<br>MfG
<br>P

[Andreas Kosch]

Hallo,

der Einsatz von ADO macht in der Regel nur dann Sinn, wenn ein <i>OLE DB Provider</i> oder ein <b>voll</b> funktionstüchtiger <i>ODBC</i>-Treiber (ab Version 3.x) zur Verfügung steht. Im Fall des InterBase trifft beides nicht zu, so dass aus meiner Sicht ADO nur als möglicher Weg zum Datenimport/Datenexport in/aus InterBase sinnvoll ist

[Patrick Sack]

Vielen Dank