SQL0954C Nicht genügend Speicher im Zwischenspeicher für Anwendungen (Application Heap)

[Walter Montigny]

Hallo,
zur Zeit stelle ich eine bisher D5 / Paradox Anwendung auf D6 / Ado / DB2 um. Versuche es!!

Die Anzeiger aus verschiedenen Tabellen wird mit AdoSQL durchgeführt.

Mir ist zwar klar, was die obige Fehlermeldung aussagt, jedoch habe ich bisher keinen Weg gefunden, diesen Fehler abzustellen.

Kann mir jemand einen Tipp geben?

Walter Montigny

[Andreas Kosch]

Hallo,

da sieht so aus, als ob mit einem clientseitigen Cursor <b>clUseClient</b> versucht wird, eine sehr grosse Tabelle zu öffnen. ADO (genauer gesagt die <i>OLE DB Cursor Engine</i>) versucht in diesem Fall, sofort alle (!) Datensätze der Tabelle in den Arbeitsspeicher des Clients zu laden. Als Abhilfe sollte eine passende WHERE-Einschränkung erfolgreich sein

[Walter Montigny]

Hallo Herr Kosch, zunächst vielen dank für Ihre Antwort.

Die Tebellen sind nicht besonders groß. Ca. 400 DS.
CursorLocation steht auf clUseServer, CursorType auf ctKeyset, LokType auf ltPessimistic.

Der Aufruf:
begin
with DDM.adoQGericht do
begin
SQL.clear;
if Edit1.Text='ALLE' then
SQL.Add('Select * from Gericht') else
if MEpruefen then
begin
SQL.Add('Select * from Gericht where Ort LIKE '+A);
end else
begin
SQL.Add('Select * from Gericht where Ort=:Ort');
if edit1.text<>'' then
with Parameters.items[0] do
begin
value:=edit1.text;
end;
end;
SQL.Add('Order by Ort');
open;
if Recordcount<>0 then speedbutton3.enabled:=true;
DBNavigator1.Datasource:=DDM.QSGericht;
end;
end else

Das jeweilige Ergebnis liegt bei ca 10-15 Datensätzen.

Das Problem tritt auch nicht sofort auf, sondern nur dann, wenn ich mehrfach hintereinander suche (like "A", like "B" usw).

Der vollständige Fehlertext lautet:
[IBM][CLI Driver][DB2/NT]SQL0954C Nicht genügend Speicher im Zwischenspeicher für Anwendungen (Application Heap) für die Verarbeitung der Anwendung.SQLState = 57011 {SQL Prepare}.

Gru&#223

[Andreas Kosch]

Hallo,

wenn clUseServer verwendet wird, liegt das Problem nicht nicht auf dem Client-Rechner, sonder direkt bei der ORACLE-Datenbank. Bei einem serverseitigen Cursor nutzt ADO das für Client/Server typische Verhalten der SQL-Datenbanken aus. Das Ergebnis der SELECT-Abfrage wird nicht sofort zum Client transportiert, sondern bleibt als Ergebnismenge mit einem geöffneten Server-Cursor bei ORACLE. Die Datenbank wartet nun darauf, dass der Client alle Datensätze einzeln abholt, den Cursor am Ende wieder schließt und den Prepare-Vorgang rückgängig macht.

In Ihrem Beispiel wird der SQL-Text zur Laufzeit immer wieder der gleichen Komponente zugewiesen und zudem auf Prepare/Unprepare verzichtet. Anscheinend nimmt das ORACLE übel, indem solange jede "alte" Ergebnismenge stehen bleibt und nur eine neue hinzugefügt wird, bis die ORACLE-Ressourcen für diese Session am Ende sind. Es wird doch auch bei ORACLE ein Tool geben, mit dem man sich die von ADO/OLE DB generierten SQL-Anweisungen anschauen kann. Die wichtige Frage ist, wie dieser ORACLE-Treiber die angeforderte pessimistische Sperre umsetzt