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

[Bodenseematze]

Zitat von Delphi.Narium:

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?!

Zitat von Delphi.Narium:

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ß).

Zitat von Delphi.Narium:

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...

Zitat von Delphi.Narium:

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...)

Zitat von Delphi.Narium:

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...

[Delphi.Narium]

Zitat von Bodenseematze:

Bezieht das jegliche VARCHAR-Spalten mit ein? Oder nur die "langen"?

Bezieht sich wohl auf alles, was nicht einer festen Länge entspricht. Und da fällt halt VarChar (leider) auch drunter.

Die ODBC-Konfiguration geht wohl über einen anderen Weg als die direkte Treiberkonfiguration in der BDE, so dass da schon mal "leichte" Missverständnisse auftreten können.

Zitat von Bodenseematze:

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?

Diese Frage verstehe ich nicht so recht. Bei den mir bekannten BDE-Komponenten TTable und TQuery gibt es keine Möglichkeit um jeweils SQL-INSERT/-UPDATE/-DELETE-Statements anzugeben.

TQuery hat die Eigenschaft SQL, das ist 'ne Stringliste, in der man beliebiges SQL angeben kann. Ein Select wird mit TQuery.Open ausgeführt und man erhält die Ergebnismenge. Alles Andere wird mit TQuery.ExecSQL ausgeführt.

Da gibt es bei den Standardkomponenten von Delphi 7 keinen Unterschied zwischen BDE und ADO. Hast Du da für die BDE-Komponenten eventuell "irgendwelche" Nachfahren im Einsatz, die da schon entsprechend erweitert wurden?

Zitat von Bodenseematze:

..., das bedeutet doch aber, dass man die Speicherung (wenn der SELECT auf einem nicht updatebare DB-View stattfindet) manuell machen muss, oder?

ja.

Zitat:

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...

Eigentlich ja. Wie kommen denn momentan die Daten in die Paradoxtabellen? Werden die Daten überhaupt zwingend als Datenbankdateien auf der Festplatte benötigt?

Wenn nein, sollte es möglich sein an der Stelle, an der momentan die Daten in die Paradoxtabellen kommen, TClientDataSet bzw. TJvMemoryData (oder alles, was "irgendwie" von TDataSet abgeleitet wurde und nur im Speicher vorhanden ist) einzusetzen.

Statt Paradox per BDE wäre aber auch noch der Einsatz von TDBF möglich. Das unterstützt (nicht vollumfänglich) dBase-Dateien ohne BDE. Man hat damit die Daten auch als Datenbankdateien auf der Festplatte zur Verfügung. Für kleinere Datenmengen eventuell eine Option, da auch andere Software, die dBase unterstützt, damit arbeiten könnte. Was ich nicht weiß ist, ob TDBF inzwischen auch Memos und Indexdateien von dBase unterstützt.

[Bodenseematze]

Zitat von Delphi.Narium:

Zitat von Bodenseematze:

Bezieht das jegliche VARCHAR-Spalten mit ein? Oder nur die "langen"?

Bezieht sich wohl auf alles, was nicht einer festen Länge entspricht. Und da fällt halt VarChar (leider) auch drunter.

Zitat von Delphi.Narium:

Diese Frage verstehe ich nicht so recht. Bei den mir bekannten BDE-Komponenten TTable und TQuery gibt es keine Möglichkeit um jeweils SQL-INSERT/-UPDATE/-DELETE-Statements anzugeben.

Man kann über das TQuery-Property UpdateObject DeleteSQL, InsertSQL und ModifySQL-Statements angeben;
s.a. https://docwiki.embarcadero.com/Libr...t.UpdateObject
Und so ein UpdateObject habe ich bei TADOQuery nicht gefunden...
EDIT: auch FireDAC hat in seiner Query-Klasse TFDQuery ein UpdateObject ; auch die Interbase-Variante hat sowas - nur eben anscheinend die ADO-Variante nicht...

Zitat von Delphi.Narium:

Zitat von Bodenseematze:

..., das bedeutet doch aber, dass man die Speicherung (wenn der SELECT auf einem nicht updatebare DB-View stattfindet) manuell machen muss, oder?

ja.

Das wäre doof - aber natürlich machbar (ggf. über eine Ableitung...)

Zitat von Delphi.Narium:

Eigentlich ja. Wie kommen denn momentan die Daten in die Paradoxtabellen? Werden die Daten überhaupt zwingend als Datenbankdateien auf der Festplatte benötigt?

Vergiss' mal die Paradox-Tabellen - die sind "flach" und tabellenmäßig einfach und werden mit technischen Berechnungsergebnissen direkt vor dem Aufruf von CrystalReports gefüllt; dafür werden z.Zt. TTable-Objekte verwendet...

Die o.a. TQuery sind für die Abfrage und Änderung der Daten vom MS-SQLServer da - das ist (datenbanktechnisch) der wesentlich komplexere Teil...

Zitat von Delphi.Narium:

Wenn nein, sollte es möglich sein an der Stelle, an der momentan die Daten in die Paradoxtabellen kommen, TClientDataSet bzw. TJvMemoryData (oder alles, was "irgendwie" von TDataSet abgeleitet wurde und nur im Speicher vorhanden ist) einzusetzen.

Ich bin da auf der Suche nach Beispielen / Erklärungen, wie das über Master-/Detail-Beziehungen mit Bezügen zu "echten" Datenbank-Datasets inkl. am besten gemacht wird...

Ich habe da noch eine (automatische) Hintergrund-Auswertung der TField-Objekte auf den Masken um geänderte Datenbankfelder optisch zu markieren - das sollte damit natürlich auch noch funktionieren / durdchführbar sein

Zitat von Delphi.Narium:

Statt Paradox per BDE wäre aber auch noch der Einsatz von TDBF möglich.

Das schaue ich mir auf jeden Fall mal genauer an - das DBF-Format wäre tatsächlich eine Option; wobei dann ca. 150 Reportdateien angepasst werden müssten - das ist dann auch wieder eine nicht zu unterschätzender Aufwand.
Da gefällt mir die Möglichkeit, das über MS Paradox ODBC-Treiber zu lösen, wesentlich besser

[Delphi.Narium]

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Diese Frage verstehe ich nicht so recht. Bei den mir bekannten BDE-Komponenten TTable und TQuery gibt es keine Möglichkeit um jeweils SQL-INSERT/-UPDATE/-DELETE-Statements anzugeben.

Man kann über das TQuery-Property UpdateObject DeleteSQL, InsertSQL und ModifySQL-Statements angeben;
s.a. https://docwiki.embarcadero.com/Libr...t.UpdateObject
Und so ein UpdateObject habe ich bei TADOQuery nicht gefunden...

Jetzt arbeite ich schon seit gefühlt 'nem viertel Jahrhundert mit Delphi, aber die Property ist mir bei TQuery noch nicht aufgefallen Zeit für die Rente 'ne, hat TADO... nicht.

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Eigentlich ja. Wie kommen denn momentan die Daten in die Paradoxtabellen? Werden die Daten überhaupt zwingend als Datenbankdateien auf der Festplatte benötigt?

Vergiss' mal die Paradox-Tabellen - die sind "flach" und tabellenmäßig einfach und werden mit technischen Berechnungsergebnissen direkt vor dem Aufruf von CrystalReports gefüllt; dafür werden z.Zt. TTable-Objekte verwendet...

TDBF könnte weitgehend mit TTable kompatibel sein, zumindest die Sachen, die für einfaches Datenrein, Datenraus genutzt werden.

Einkonstrukt TDBGrid - TDataSource - TTable kann problemlos in TDBGrid - TDataSource - TDBF umgewandelt werden, da beides Nachkommen von TDataSet. Überall dort, wo zwischen der Datenverarbeitung, Report, Datenanzeige ein TDataSource steckt, sollte daher TTable durch TDBF ausgetasucht werden können. Wie werden die TTables befüllt? Sinngemäß sowas?

Delphi-Quellcode:

  while not IrgendeineDBKomponente.EoF do begin
    TTable.Append;
    TTable.FieldByName('irgendwas').AsIrgendeinTyp := IrgendeineDBKomponente.Fields[0].AsIrgendEinType; // hier können auch Funktionsergebnisse hinterstecken ...
    ...
    TTable.Post
    IrgendeineDBKomponente.Next;
  end;

Das sollte mit TDBF funktionieren, grob gesagt: TTable wegwerfen und durch TDBF gleichen Namens ersetzen, wäre die einfachste Möglichkeit. Hoffentlich hast Du da das Glück, dass es so einfach geht.

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Wenn nein, sollte es möglich sein an der Stelle, an der momentan die Daten in die Paradoxtabellen kommen, TClientDataSet bzw. TJvMemoryData (oder alles, was "irgendwie" von TDataSet abgeleitet wurde und nur im Speicher vorhanden ist) einzusetzen.

Ich bin da auf der Suche nach Beispielen / Erklärungen, wie das über Master-/Detail-Beziehungen mit Bezügen zu "echten" Datenbank-Datasets inkl. am besten gemacht wird...

Meinst Du über die Attribute MasterSource und MasterFields? Die hat TClientDataSet auch. Damit dürfte es eigentlich keine grundsätzlichen Unterschiede geben, aber wer weiß. Da müsst man jetzt echt mal in die Quelltexte Deiner Software schauen, um sinnvoll helfen zu können.

Zitat von Bodenseematze:

Ich habe da noch eine (automatische) Hintergrund-Auswertung der TField-Objekte auf den Masken um geänderte Datenbankfelder optisch zu markieren - das sollte damit natürlich auch noch funktionieren / durdchführbar sein

Hier wäre ich optimistisch, dass das durch Austausch der Datenbankkomponenten trotzdem transparent bleibt und "einfach" funktioniert.

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Statt Paradox per BDE wäre aber auch noch der Einsatz von TDBF möglich.

Das schaue ich mir auf jeden Fall mal genauer an - das DBF-Format wäre tatsächlich eine Option; wobei dann ca. 150 Reportdateien angepasst werden müssten - das ist dann auch wieder eine nicht zu unterschätzender Aufwand.
Da gefällt mir die Möglichkeit, das über MS Paradox ODBC-Treiber zu lösen, wesentlich besser

Wenn die Minus Eins im Blobcache das Problem gelöst hat, wäre die Umstellung auf den ODBC-Treiber auch meine erste Option.

[Bodenseematze]

[QUOTE=Delphi.Narium;1530533]

Zitat von Bodenseematze:

Jetzt arbeite ich schon seit gefühlt 'nem viertel Jahrhundert mit Delphi, aber die Property ist mir bei TQuery noch nicht aufgefallen Zeit für die Rente 'ne, hat TADO... nicht.

Zitat von Delphi.Narium:

TDBF könnte weitgehend mit TTable kompatibel sein, zumindest die Sachen, die für einfaches Datenrein, Datenraus genutzt werden.

Ja, das schon - aber wie gesagt: der Aufwand liegt hier auf der Reportseite, wenn hier 150 Reports angepasst werden müssen
--> da werde ich versuchen, auf die Variante mit der MS Paradox-Schnittstelle umzustellen...


[QUOTE=Delphi.Narium;1530533]Wie werden die TTables befüllt? Sinngemäß sowas?

Delphi-Quellcode:

  while not IrgendeineDBKomponente.EoF do begin
    TTable.Append;
    TTable.FieldByName('irgendwas').AsIrgendeinTyp := IrgendeineDBKomponente.Fields[0].AsIrgendEinType; // hier können auch Funktionsergebnisse hinterstecken ...
    ...
    TTable.Post
    IrgendeineDBKomponente.Next;
  end;

Ja, und bei mir ist es sogar noch einfacher, weil die TTable immer nur einen Datensatz hat...

Zitat von Delphi.Narium:

Meinst Du über die Attribute MasterSource und MasterFields? Die hat TClientDataSet auch. Damit dürfte es eigentlich keine grundsätzlichen Unterschiede geben, aber wer weiß. Da müsst man jetzt echt mal in die Quelltexte Deiner Software schauen, um sinnvoll helfen zu können.

Nein, ich meinte das prinzipielle Verhalten mit Events, Updates, Öffnen, Schließen, Sätze weiterschalten etc. und was ich (sinnvollerweise) wo und wie miteinander verknüpfen muss, um das Master-/Detail-Verhalten zu erreichen.

Zitat von Delphi.Narium:

Wenn die Minus Eins im Blobcache das Problem gelöst hat, wäre die Umstellung auf den ODBC-Treiber auch meine erste Option.

Scheint aktuell so

[Delphi.Narium]

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

TDBF könnte weitgehend mit TTable kompatibel sein, zumindest die Sachen, die für einfaches Datenrein, Datenraus genutzt werden.

Ja, das schon - aber wie gesagt: der Aufwand liegt hier auf der Reportseite, wenn hier 150 Reports angepasst werden müssen
--> da werde ich versuchen, auf die Variante mit der MS Paradox-Schnittstelle umzustellen...

Greifen denn die Reports direkt auf TTable / TQuery oder die Paradoxdateien zu oder liegt da noch 'ne TDataSource zwischen?
Liegt da noch 'ne TDataSource zwischen, sollte es reichen dieser beim DataSet "einfach" eine andere Datenbankkomponente zuzuweisen. Solange sich weder Spaltenname noch Spaltentyp ändern, sollte der Austausch der Datenbankkomponenten ohne weiteres funktionieren.

Report -> TDataSource -> TTable
kann man ändern in
Report -> TDataSource -> TDBF
oder
Report -> TDataSource -> TADOTable
oder
Report -> TDataSource -> TClientDataSet

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Meinst Du über die Attribute MasterSource und MasterFields? Die hat TClientDataSet auch. Damit dürfte es eigentlich keine grundsätzlichen Unterschiede geben, aber wer weiß. Da müsst man jetzt echt mal in die Quelltexte Deiner Software schauen, um sinnvoll helfen zu können.

Nein, ich meinte das prinzipielle Verhalten mit Events, Updates, Öffnen, Schließen, Sätze weiterschalten etc. und was ich (sinnvollerweise) wo und wie miteinander verknüpfen muss, um das Master-/Detail-Verhalten zu erreichen.

Eigentlich ist das Meiste identisch. Alles, was von TDataSet geerbt wurde, stimmt überein.

Open, Close, BeforePost, AfterScroll, Active ... haben die alle und es verhält sich überall gleich. Auch die Zuweisung der Ereignisroutinen im Objektinspektor sollte gleich sein.

Hast Du für eine TTable z. B. eine Routine für AfterScroll, so kannst Du genau diese Routine auch 'ner TADO... beim AfterScoll zuweisen. Solange im Quelltext der Routinen nicht auf die Datenbankkomponente zugegriffen wird, sondern nur über den im Prozedurekopf übergebenen DataSet, sollte das transparent sein. Selbst wenn Du eine TTable durch eine TDBF ersetzt und der Name nicht verändert wird, sollte das problemlos gehen.

Z. B: Du hast eine TTable mit dem Namen Tail. Die schmeist Du nun weg und nimmst eine TDBF mit dem Namen Tail. Dann sollte das ohne weitere Änderung funktionieren, analog mit TADOTable oder TADOQuery, TClientDataSet, ...

Zitat von Bodenseematze:

Zitat von Delphi.Narium:

Wenn die Minus Eins im Blobcache das Problem gelöst hat, wäre die Umstellung auf den ODBC-Treiber auch meine erste Option.

Scheint aktuell so

Das heißt dann ja zumindest schonmal, dass es an dieser Baustelle nicht brennt und Du in Ruhe nach der bestmöglichen Alternative suchen kannst.

[Bodenseematze]

Zitat von Delphi.Narium:

Greifen denn die Reports direkt auf TTable / TQuery oder die Paradoxdateien zu

Die Reports sind Dateien mit der Endung .rpt die ein eigenes, von Crystal Reports definiertes Format vorweisen.
Sie können nur mit CR geöffnet werden und greifen dann auf Datenbanken und Drucker etc. zu, indem sie die in CR zur Verfügung stehenden Schnittstellen verwenden;
Mit dem Delphi-Wrapper, der für ältere Delphi-Versionen von CR zur Verfügung gestellt wurde, hat man die Möglichkeit, diesen Reportdateien sozusagen Parameter mitzugeben, wie z.B. welche Datenbankverbindung sie verwenden sollen oder welche(n) Datensatz sie aus der Datenbank nehmen sollen oder welchen Drucker sie verwenden sollen;
und dann lässt sich über die Schnittstelle auch noch CR selber (grob) steuern, d.h. z.B. eine Druckausgabe anstoßen oder ein Vorschaufenster öffnen
(es geht noch mehr mit der Schnittstelle aber das ist es größtenteils, was in meinem Fall verwendet wird).
d.h. bzgl. Datenbankzugriff wird in meinem Fall den Reports beim Öffnen der MS SQL (bzw. ODBC)-Datenquellname mitgegeben sowie die ID des Master-Datensatz, den sie einlesen sollen sowie das Verzeichnis, in dem die lokale Paradox-Datenbank liegt.
Die Reportdateien selber wissen nichts von Delphi - oder den Komponenten in Delphi...

Zitat von Bodenseematze:

Das heißt dann ja zumindest schonmal, dass es an dieser Baustelle nicht brennt und Du in Ruhe nach der bestmöglichen Alternative suchen kannst.

Jein ich habe noch ein (neues) Problem, bei dem ich auch nicht so recht weiß, woher es kommt - das werde ich jetzt mal versuchen, in einem neuen Thema zu formulieren...

Auf jeden Fall habe ich noch eine mehrere eigene Hilfsklassen, in der Vereinfachungen für die Datenbank-Queries und die Datenbank selber enthalten sind - die waren sehr TQuery/TDatabase lastig; die stelle ich gerade um, so dass die Schnittstellen TDataSet und TCustomConnection sind und erst intern dann je nach tatsächlich übergebenem Typ (z.B. TQuery vs. TADOQuery) unterschieden wird und unterschiedliche Aufrufe durchgeführt werden bzw. Properties gesetzt / abgefragt werden.
Das als Vorbereitung, das noch weiter zu abstrahieren bzw. eine andere Datenbankschnittstelle zu verwenden...

Der Teil mit den TTable und der Füllung der Paradox-Dateien ist sowieso komplett extra - das könnte ich dann relativ getrennt vom Rest umstellen...