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.

[jobo]

In der Feldliste ist aber kein BLOB Feld oder?

[itashadow]

Danke schoneinmal für die Rückmeldungen

Die Oracle Version konnte ich nun auch ermitteln:

NLSRTL	11.2.0.3.0	Production
Oracle Database 11g Enterprise Edition	11.2.0.3.0	64bit Production
PL/SQL	11.2.0.3.0	Production
TNS for Linux:	11.2.0.3.0	Production

Als Compiler verwende ich Lazarus und habe folgende Komponenten verwendet:

TSQLConnector
TSQLQuery
TSQLTransaction
TDatasource
TDBGrid

mit dem Admin würde ich zur Zeit ungern sprechen. Das Programm entsteht im hitnergrund. --> Es würde uns zur Zeit enorm entlasten aber bisher war es so, wenn wir 10% last weniger hatten, kamen 20% mehr arbeit hinzu.

Abgefragt wird ein VARCHAR2(64 Byte) wobei es insgesamt nur 75 einträge in der Datenbank gibt. Wenn ich per Whereklausel das ganze so einschränke, dass nur ein Wert ausgegeben werden soll, dann bekomme ich den gleichen Fehler. --> Es handelt sich um einen zusammenhängenden text mit Buchstaben, Zahlen, doppelpunkten und unterstrichen. der längste ist 65 Zeichen lang. Durchschnitt dürfte bei 30 Zeichen liegen.

mit "die Abfrage hat schon funktioniert" wollte ich nur ausdrücken, dass die Connection prinzipiell funktioniert und es wahrscheinlich etwas mit den Feldern zu tun hat. --> Wenn ich das gleiche SQL-Statement im PLSQL-Developer ausführe bekomme ich das richtige ergebnis.

Kann mir vielleicht jemand sagen, wie ich mir bei dem TSQLQuery die MaxBufferSize ausgeben lassen kann? Die varianten die ich im Netz gefunden habe, haben alle nicht funktioniert

[jobo]

Die Fehlermeldung ist von Oracle, es geht um Oracle Buffer.
Vielleicht solltest Du das mit Deinem Admin klären, miteinander klappt das sicher besser als heimlich.

Welche Oracle Client Componenten/ Version verwendest Du?
(SDAC geht über OLEDB, oder?) Das war quatsch, hab ich mit anderem Thread verwechselt.

PL/SQLDeveloper geht nativ an OCI.

[itashadow]

ein umstellen von TSQLConnector auf TOracleConnection hat geholfen.