Lesen ORACLE varchar-Feld :BLOB-Fehler ?!?! Hr. Kosch ?!

[Wolf Fietz]

also, das ist schon komisch :
Die Delphi-5-prof.Anwendung (ORACLE 8.1.5 BDE-direkt-Anbindung,kein ODBC!)läuft einige Monate störungsfrei, Tablespaces alle ok.
Neuerdings gibt es beim Schreibversuch in ein varchar2(1024)-Feld und anschließendem Lesen folgende Fehlermeldung :
"Ungültiges BLOB-Handle in Datensatzpuffer",
bei Ausführung in Delphi-IDE zusätzlich "EDBEngineError"

????

MfG
Wolf Fietz

ps : der fehler wird übrigens erst bei zuweisung der zwischenspeichervar (String !) an das MEmofeld (TMEmo) ausgegeben, nicht bereits bei der zuweisung speicher = Query.FieldByName(...).AsString; anere Möglichkeiten mit Variant brachten denselben Fehler !

Ist das ein Bug ?

[Andreas Kosch]

Mit ORACLE-Datenbanken habe ich keine Erfahrungen

[Wolf Fietz]

das ist eben das unklare : der Fehler tritt erst bei der Zuweisung
an die Memo-Komponente auf, die StringVar hat das ja offensichlich
"geschluckt"; möglicherweise dann wieder 'mal ein BDE-Bug ?

aber warum tritt das erst nach einigen Wochen auf ? gibt es
irgendwo eine Datei im Pascal- oder BDE-System, die
"vollaufen" könnte ? Im ORACLE-Bereich wurde jedenfalls
alles kontrolliert, aber wer weiß...;von denen kriege ich keine
brauchbare Antwort..

?????????

MfG
W.Fiet

[Wolf Fietz]

Neuere Erkenntnisse ( 04.10.2001) :

Der genannte Fehler (BLOB-Handle..)tritt auf, wenn ein neuer Datensatz mit SQL-INSERT
hinzugefügt wurde. DEr BDE-Datenbrowser zeigt den angefügten Satz korrekt an; bei der Anweisung mytext := qry.fieldbyname('vermerk').AsString bringt den Fehler !

Die Variable mytext ist lokal als String deklariert.

Wenn aber nach dem INSERT ein Datensatz mit SQL-DELETE (in der laufd. Anwendung) gelöscht wird (irgendein anderer), dann lassen sich alle Sätze mit der o.g.
Anweisung einwandfrei lesen.

Nach dem nächsten INSERT : Fehler !
Nach dem nächsten DELETE : ok !

nach Index Refresh : keine Änderung !

schon lustig , nicht wahr !???????????????????

HIIIIIILLLLLLLLLLFFFFFFFFFEEEEEEEEEEEEE !!!!!!!!

MfG
Wol

[Andreas Kosch]

Hallo,

bei derartigen Problemen muss man die Ursache Schritt für Schritt einkreisen. Ich würde daher folgendes machen: <br>
1. Transaktion starten<br>
2. INSERT fügt neuen BLOb-Datensatz ein <br>
3. Transation über Commit beenden <br>
4. SELECT-TQuery schliessen <br>
5. SELECT-TQuery neu öffnen, wobei in der WHERE-Einschränkung nur der Primärschlüsselwert verwendet wird, der zu dem im Schritt 2 neu eingefügten Datensatz passt.

Tritt das Problem dann immer noch auf

[Wolf Fietz]

danke für Anwort, Hr. Kosch

1.) TA starten,commit : hatte ich auch vermutet, hat sich aber nicht bewahrheitet : FEHLER = KONSTANT :-)

Übrigens trat der Fehler auch dem BDE-Datenblatt-Tool nicht auf ,also
2.) ganz dummer Test :
//- Original-Abfrage (bringt BLOB-Fehler):
//vSQL := 'SELECT * FROM ' + TBL_EVENTS + ' ORDER BY eventid DESC';
//- test :
vSQL := 'SELECT * FROM ' + TBL_EVENTS;

QryEvent.SQL.Add(vSQL);

BLOB-Fehler trat nicht mehr auf ! :-))

also ein Navigationsproblem bei TQuery !?

(übrigens, die vorherige Zuordnung des SQL-Strings zu einer Variablen
geschieht nur zur Kontrolle in der Entwicklungsumgebung wg. möglicher CONCAT-Fehler..)

MfG
Wolf Fiet

[Andreas Kosch]

Hallo,

es ist unüblich, bei umfangreichen BLOb-Daten gleich mehrere Datensätze zu laden. Daher verwendet die BDE einen begrenzten BLOb-Cache, der nur wenige BLOb-Inhalte tatsächlich speichert. Normalerweise holt man sich die BLOb-Daten <b>einzeln</b> ab - wenn also eine sortierte (ORDER BY) Darstellung aller Datensätze im TDBGrid benötigt wird, dann bitte schön <b>ohne</b> BLOb-Spalte. Wird ein Datensatz ausgewählt, holt sich eine 2. SELECT-Abfrage nur den BLOb-Inhalt vom gerade ausgewählten Datensatz. Bei diesem Vorgehen kann dieser Fehler nicht mehr auftreten, da die Beschränkungen des BLOb-Cache der BDE nicht mehr greifen.

P.S: In der BDE-Verwaltung ist der BLOb-Cache der BDE für ORACLE auf 64 Einträge voreingestellt

[Wolf Fietz]

Danke, Hr. Kosch !!

Die Datensatzmenge kann noch recht groß werden; also lese ich das Memofeld dann extra ein..;wieder was gelernt !

Übrigens, wenn man bei der o.g. SQL den Passus 'ORDER BY... ' oder
auch nur '..DESC' wegläßt, tritt der Fehler auch nicht mehr auf !
Wieso eigentlich nicht ???? Fast wie bei JAVA : lesen nur in einer (nativen) Richtung ?

MfG
Wol

[Andreas Kosch]

Hallo,

das wird damit zu tun haben, dass es BLOb-Daten zu Beginn des Zeitalters der SQL-Datenbanken nicht gegeben hat. Jeder Datensatz (der zum Client transportiert werden musste) konnte vorher in seiner Länge exakt berechnet werden, so dass sowohl der SQL-Server als auch der Client den notwendigen Speicherplatz für den Puffer fest einrichten konnte. Dann kamen die BLObs mit ihrer variablen Länge und passten in dieses Schema nicht rein - so dass sich jeder Hersteller etwas anderes einfallen lassen musste. Da ich mit ORACLE-Datenbanken nicht hantieren muss, habe ich bisher nicht nachgelesen, wie das dort gehandhabt wird :-

[Wolf Fietz]

das ist wohl so, wie Sie sagen !
Zunächst wußte ich garnicht, daß ich da mit BLOB umgehe;
denn die Feld-Definition ist varchar2(1024); also bin ich ganz dumm
von einem "stinknormalen" Zeichenfeld ausgegangen...so kann man sich irren ! :-))

Nochmals vielen Dank für Ihre Hilfe ! Wohin geht jetzt der Kasten Bier ?

MfG
Wol

[Wolf Fietz]

Nachtrag : der BLOB-Bug scheint nur bei TQuery aufzutreten,
bei TTable tritt er bsiher (bei 3facher Datensatzmenge) nicht auf