Einzelnen Beitrag anzeigen

Bodenseematze

Registriert seit: 10. Jul 2023
50 Beiträge
 
#9

AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze

  Alt 7. Dez 2023, 10:54
BLOBS TO CACHE bezieht sich auf Blobfelder und nicht auf Datensätze.
99 Datensätze mit jeweils 6 Blobspalten / VarCharspalten ist bereits mehr als 512 Blobs im Cache.
Bezieht das jegliche VARCHAR-Spalten mit ein? Oder nur die "langen"?
Wenn es nur die "langen" sind (die, die als BLOB interpretiert werden), ist es bei mir nur eine Spalte pro Datensatz - d.h. bei 100 Datensätzen (der Master-Datensatz hat auch eine BLOB-Spalte) sind es 100 * 1,5=150 - da sollte eigentlich 512 als Wert massig ausreichen, oder?!


Womit kommt denn Crystal Reports zurecht? Alles was "irgendwie" von TDataSet abgeleitet ist, was bei TTable, TQuery, TADOTable, TADOQuery, ... der Fall ist?
Nein, es geht hier um die Reportdateien selber - die wissen nichts von Delphi;
in Delphi verwende ich einen sog. VCL-Wrapper für Crystal Reports (CR) - das ist Delphi-Code, der auf eine spezielle CR-DLL zugreift; damit lassen sich CR starten und Report-Dateien in CR öffnen, drucken und/oder anzeigen. Über den Delphi-Wrapper lassen sich im Report Informationen setzen (z.B. welcher Drucker er nehmen soll, welche Datenbankschnittstelle bzw. welcher DB-Server, ...).
Die Zugriffe selber erfolgen dann aber über den Report (bzw. über CR) - was damit also geht, hängt von CR ab.
CR verfügt über einige DB-Schnittstellen; für lokale DBs aber leider nicht sooo viel (zumindest in der Version v9, die ich verwende/verwenden muß).


Last holt sofort alle Sätze, deshalb passiert der Fehler sofort. Ohne Last passiert er beim Scrollen im Grid (oder in 'ner Schleife per Next) sobald die 512 Blobs überschritten sind.
Das kann schon sein...

Ich habe jetzt im BDE-Administrator mal direkt an der ODBC-Datenquelle nachgeschaut - dort steht doch tatsächlich BLOBS TO CACHE=64
und das obwohl am dazugehörigen Treiber 512 gesetzt ist - bei einer anderen ODBC-Datenquelle, die den selben Treiber verwendet, steht der korrekt Wert.
An den Datenquellen lässt sich der Wert im BDE-Admin auch nicht verändern...

Eventuell aber auch in der TDataBase-Komponente (soweit sie genutzt wird) bei Params mal BLOBS TO CACHE=-1 angeben.
Ich habe jetzt in meinem Code bei der TDatabase als Parameter BLOBS TO CACHE=-1 hinzugefügt und beim Master-Datensatz (im AfterScroll) nach dem Öffnen des Detail-Queries ein Tail.Last() wieder eingefügt.
Bei meinen bisherigen Tests, die in der Vergangenheit zuverlässig zum Fehler geführt hatten, ist nichts mehr passiert - der Fehler scheint damit weg zu sein
(ich habe aktuell noch einen anderes Problem im Zusammenhang mit der Datenbank - aber das schreibe ich dann in einem neuen Thema...)


Die ADO-Komponenten funktionieren eigentlich (fast) wie die BDE-Komponenten. Eine Umstellung sollte hier recht einfach durchzuführen sein. Ein paar Attribute haben ähnliche Namen, aber grundsätzliche Probleme sollte es nicht geben.
Entweder verstehe ich die Komponenten nicht, oder ich bin zu blöd dafür - aber soweit ich verstanden habe, fehlen den ADO-Komponenten die Möglichkeit, SQL-INSERT/-UPDATE/-DELETE-Statements anzugeben - das bedeutet doch aber, dass man die Speicherung (wenn der SELECT auf einem nicht updatebare DB-View stattfindet) manuell machen muss, oder?


Wäre es eigentlich möglich, meine aktuell vorhandenen TQuery-Komponenten (einfach) auf TClientDataSet-(bzw. JvMemData-)Komponenten umzustellen und dann per Programmcode mit entsprechenden "echten" Datenbank-DataSets (testweise entweder TQuery oder auch angepasste TADOQuery bzw. JvADOQuery) zu verknüpfen?
Dann hätte ich wenigstens schon eine Abstraktionsebene mehr drin
Mir ist nur noch nicht so klar, wie ich das "richtig" machen soll...
  Mit Zitat antworten Zitat