TSQLQuery Puffer-Problem

[itashadow]

Hallo Leute,

ich versuche gerade ein kleines Status-Tool zu schreiben, welches Daten aus einer Datenbank abfragt und diese dann überprüft bzw. bearbeitet. Da ich noch totaler Delphi-Datenbank-Neuling bin, habe ich Bei folgenden Quellcode ein Problem:

Delphi-Quellcode:

      SQLQuery1.Close;
      SQLQuery1.SQL.Clear;
      SQLQuery1.SQL.Text := 'select cname from tschedulertask';
      SQLQuery1.Open;

sobald er das Open ausführt, kommt folgende Fehlermeldung:

Zitat:

ORA-01062: Speicher f?r Define-Puffer kann nicht zugewiesen werden

Die Tabelle Tschedulertask hat folgende Daten:

CID	CHAR(36 BYTE)	No		1	Unified ID
CNAME	VARCHAR2(64 BYTE)	No		2	descriptive name for task configuration
CACTIVE	NUMBER(1,0)	No		3	flag for (de-)activation of the task
CCOMMENT	VARCHAR2(1024 BYTE)	Yes		4	optional comment
CCREATED	TIMESTAMP(6)	Yes		5	Datetime of task creation
CLASTMODIFIED	TIMESTAMP(6)	Yes		6	Datetime of last task modification
CCREATEUSER	VARCHAR2(256 BYTE)	Yes		7	User who created the task
CLASTUSER	VARCHAR2(256 BYTE)	Yes		8	Last user who modified the task
CENV	CHAR(3 BYTE)	No		9	BIS client
CPROFILE	VARCHAR2(64 BYTE)	Yes		10	Name of a profile/group
CNEXTEXECUTION	TIMESTAMP(6)	Yes		11	Datetime of next execution
CLASTEXECUTION	TIMESTAMP(6)	Yes		12	Datetime of last execution
CSITEREF	CHAR(36 BYTE)	No		13	Reference to the site
CQOS	NUMBER(5,0)	Yes		14	Quality of service

Eigentlich soll später dieses SQL ausgeführt werden. Aber das klappt ja auch noch nicht.

'select cid, substr(clastexecution,0,14), substr(cnextexecution,0,14), ctrigger, cactive from tschedulertask '

Wenn ich hingegen nach cactive frage dann klappt es. Wenn ich in einer anderen Tabelle nach VARCHAR(255 Byte) frage, dann klappt das auch --> da sollten ja mehr Daten stehen.

Woran kann das liegen?

Ich bin für jede Hilfe dankbar

Gruß

itashadow

edit: mist. hatte den betreff nur eingegeben, damit ich die Vorschau verwenden kann. Kann jemand bitte den Titel anpassen? --> "TSQLQuery Puffer-Problem" oder so ähnlich

[p80286]

edit: mist. hatte den betreff nur eingegeben, damit ich die Vorschau verwenden kann. Kann jemand bitte den Titel anpassen? --> "TSQLQuery Puffer-Problem" oder so ähnlich[/QUOTE]

Kein Problem, Du gehst auf Bearbeiten(Deines ersten Beitrags) und unter Erweitert gibt's Die Möglichkeit den Titel zu ändern.

An Deiner Abfrage gibt's nichts auszusetzen, die sollte eigentlich überall laufen.
Also hast Du TSQLQuery richtig eingerichtet (Connection) usw.

Versuch es doch einmal spasseshalber mit ADO(connection/query).
(die sind ja eigentlich immer kostenlos dabei)

Gruß
K-H

[itashadow]

das komische ist ja, dass 5 andere Abfragen funktionieren und haben eigentlich einen größeren speicherverbrauch. Die gleiche Fehlermeldung gibt es auch bei CLASTEXECUTION.

aber ich werd mich mal mit ADO beschäftigen und mich mal einlesen.

Hat vielleicht noch jemand einen Tipp?

Gruß

itashadow

[p80286]

entschuldigung, ich hatte die ursprüngliche Nachricht nicht richtig gelesen:

Zitat:

ORA-01062: unable to allocate memory for define buffer Cause: Exceeded the maximum buffer size for current plaform
Action: Use piecewise fetch with a smaller buffer size

Da würde ich zunächst einmal einen Blick auf die Connection werfen, und den Admin interviewen.
Nur "die Abfrage hat schon funktioniert" hat überhaupt keinen Wert. (leider)

Gruß
K-H

[jobo]

Das könnte ein Oracle Bug sein, die Version, die Du nicht angegeben hast, scheint mir da schon spannend.
Ich kenne aus 10.2xy Bugs bei bestimmten Konstellationen von NLS Settings und der Abfrage von timestamp Feldern aus den Oracle-eigenen task scheduler dictionary views.
Deine weiterführende Abfrage sieht auch so ein wenig grob aus. Substring auf Timestamp muss nicht immmer wie gewünscht funktionieren.

[Bernhard Geyer]

Oracle und Bug? Kann niemals sein.

Gibt doch mal an was genau verwendet wird? Evtl. liegt hier auch ein Bug vor den ich auch vor kurzen hatte. Die Zugriffskompos(Oder war der NET-Client) hat für jeden BLOB/TEXT-Feld mehrere MB an Speicher reservier obwohl nur ein paar Bytes benötigt wurde. Dann war schon nach wenigen (100) Ergebnisdatensätzen Schluss mit lustig.