ADODataSet mit SQL-Abfrage - Fehler bei Append

[chris.s]

Ich nutzte bisher ein ADODataSet als Zugriff auf eine Tabelle (cmdTable) und filtere die Daten entsprechend (clUseClient). Dies ist bei wachsender Zahl der Datensätze (>40000) und weniger benötigter Datensätze (ca. 100) sehr zeitaufwändig. Mit Serverseitigem Cursor ist die Geschwindigkeit auch nicht besser (>15 Sek.). Der Versuch, eine SQL-Abfrage mit entsprechender WHERE-Klausel zu verwenden, ist prinzipiell erfolgreich. Versuche ich jedoch, die Methoden EDIT oder APPEND des ADODataSet anzuwenden, bekomme ich die Fehlermeldung des ADO: nicht genügend Basistabelleninformationen. Primary Key und weitere Indizes existieren. Die Fields sind registriert. Änderung des Cursors bringt keinen Erfolg. Weiß jemand Rat?

[MarcoWarm]

am sichersten ist es meist die Daten mittels SQL direkt in die Tabelle zu schreiben (mit TADOCommand). Das funktioniert eigentlich immer und ist IMHO wesentlich übersichtlicher - zumal man so die Dauer der offenen Transaktionen verkürzen kann.

[chris.s]

Hallo Marco,

vielen Dank für die Antwort. Leider ist es nicht möglich, in jedem Fall direkte SQL-Statements zu benutzen, da diesem ADODataSet ein Kalender-Steuerelement (TMS DBPlanner) zugeordnet ist. Dieser ist aber für das Problem der Fehlermeldung aus meiner Sicht nicht verantwortlich, da ich die Fehlermeldung auch mit einfachen Steuerelementen und direkten ADO-Zugriffen erzeugen kann. Vielmehr scheint es so zu sein, daß man bei SQL-Datenmengen, auch wenn sie nur auf eine Basistabelle zurückgreifen, die Daten nicht anhängen kann. Ich kenne diese Methode z. B. aus Access, wo das z. B. mit DAO problemlos möglich ist, solange die SQL-Query nur eine Tabelle abfragt.
Alternativ wäre ja auch der Zugriff auf die Tabelle (cmdTable) möglich. Das Problem dabei ist jedoch, daß offensichtlich vor der Filterung unabhängig vom Cursor erst einmal alle Daten hochgeladen werden, was äußerst zeitintensiv ist. Die Daten nach Datum zu filtern gelingt in der Filtereinstellung irgendwie nicht - dieses Problem kennt man ja auch aus anderen Umgebungen: in der SQL-Query ist es kein Problem, im Filter bekomme ich - egal ob ich ' oder # benutze eine Meldung, die Filterkriterien seien nicht passend. Außerdem wirkt der Filter offensichtlich nur auf die lokale Datenmenge.

Weiß jemand Rat oder alternative Vorgehensweisen?

[MarcoWarm]

Nun, hmm :gruebel:

Du könntest die Daten des ADOQuery's in ein ClientDataSet laden. Das hat den Vorteil, daß du die Datenquelle mit DBEdits, DBPlanner etc. verknüpfen kannst. Wenn du die Daten dann postest, wird nur das ClientDataSet aktualisiert. Bei passender Gelegenheit (z.B. AfterPost) kannst Du die Änderungen dann in SQL-Scripte wandeln und ausführen. Eigentlich sollte auch die Methode ApplyUpdates des ClientDataSet funktionieren aber wahrscheinlich wird da der gleiche Fehler wie bei direktem Zugriff kommen.

Ciao

Marco

[Stevie]

Ohne jetzt jemanden zu beschuldigen sage ich einfach mal: DAS KANN NICHT SEIN!!!
Ich kann in ein DataSet immer eine Select-Anweisung mit einer Where-Klausel einschränken und trotzdem Sätze einfügen, sogar egal, ob sie der Abfrage-Bedingung entsprechen oder nicht! Man benötigt noch nichtmal irgendwelche Keys oder so.
Um näheres sagen zu können, wäre die Datenbank mal interessant zu wissen. Außerdem die Struktur der abgefragten Tabelle, und die Select-Anweisung.

[Leuselator]

Welche Datenbank benutzt Du?

[chris.s]

Zitat:

Zitat von Leuselator

Welche Datenbank benutzt Du?

Ich benutze PostgreSQL 7.1.3 auf Red-Had-Linux 7.2. Wohlgemerkt kommt die Fehlermeldung vom ADO bzw. Delphi, nicht vom Server.

Zitat:

Du könntest die Daten des ADOQuery's in ein ClientDataSet laden. Das hat den Vorteil, daß du die Datenquelle mit DBEdits, DBPlanner etc. verknüpfen kannst. Wenn du die Daten dann postest, wird nur das ClientDataSet aktualisiert. Bei passender Gelegenheit (z.B. AfterPost) kannst Du die Änderungen dann in SQL-Scripte wandeln und ausführen. Eigentlich sollte auch die Methode ApplyUpdates des ClientDataSet funktionieren aber wahrscheinlich wird da der gleiche Fehler wie bei direktem Zugriff kommen.

Habe ich bisher noch nie gemacht, werde ich mal testen!

Zitat:

Ohne jetzt jemanden zu beschuldigen sage ich einfach mal: DAS KANN NICHT SEIN!!!
Ich kann in ein DataSet immer eine Select-Anweisung mit einer Where-Klausel einschränken und trotzdem Sätze einfügen, sogar egal, ob sie der Abfrage-Bedingung entsprechen oder nicht! Man benötigt noch nichtmal irgendwelche Keys oder so.
Um näheres sagen zu können, wäre die Datenbank mal interessant zu wissen. Außerdem die Struktur der abgefragten Tabelle, und die Select-Anweisung.

Den ersten Satz sehe ich eigentlich genauso. Ich benutze jedoch kein normales DataSet, sondern ein ADO-DataSet. Wie gesagt, die Datenbank ist PostgreSQL. Die Abfrage ist denkbar simpel:

Delphi-Quellcode:

commandtext := 'SELECT tplan.* FROM tPlan WHERE ((PatientenID=1 OR PatientenID = ' + vartostr(varAufnahmenummer)+ '));

Lesezugriffe sind problemlos und erwartungsgemäß schneller als der Direktzugriff auf die Basistabelle. Die Fehlermeldung erscheint dann bei jeder Aktion, egal ob append, edit auf Code-Ebene oder eine Änderung durch das Steuerelement. Strukturell arbeite ich mit einem ADODataSet, welches über ein ADOConnection-Objekt auf die PGSQL-Datenbank im ReadWrite-Mode verzweigt. Das einzige, was mir bei der Durchsicht auffällt, ist, daß ich noch keine Änderung am Isolation-Level des Connection-Objektes (aktuell CursorStability) ausprobiert habe. Ich arbeite jedoch nicht mit Transaktionen (lediglich PGSQL macht ja AutoCommit-Transaktionen, die dürften jedoch unschuldig sein).

Vielen Dank schon mal für die Mühe!

[Stevie]

Ich hab keine Ahnung von PostgreSQL, aber wie sind den die Lese- bzw. Schreibrechte?
Das ADODataSet ist von TDataSet abgeleitet, und davon sprach ich...

Vielleicht liegt es wirklich an der Datenbank? Ich weiß nur, dass in Oracle und Access eingeschränkte Datenmengen "appended" bzw. "inserted" werden können.

[chris.s]

Lese-Schreibrechte sind vorhanden. Ich greife via ADO-OLEDB/ODBC auf den PostgreSQL-Server zu. Prinzipiell vermute ich auch, daß es am Server liegt, ich sehe jedoch keinerlei Debug-Meldung. Die Fehlermeldung sieht verdächtig nach einer ADO bzw. Delphi-Meldung aus, zumal sie in Deutsch ist, der Server aber engl. Fehlermeldungen produziert. Ob es möglich ist, für SQL-Mengen nochmals gesondert Edit-/Appendrechte auf Serverebene zu vergeben, muß ich testen.

PS: Auf ADO hatte ich nur nochmal hingewiesen, da es ja durch die ADO/OLEDB-Treiber eine weitere "Fehlerquelle" gibt.

[Stevie]

Aber ohne Where-Klausel gibt es keine Fehler, ja?
Sonst würde ich mal gucken, welche Eigenschaften bei der Connection angegeben sind.