|
"Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Hallo zusammen,
ich habe mal wieder ein Problem, von dem ich absolut nicht verstehe, wo es herkommt bzw. wie ich es umgehen kann. Ich greife mit Delphi 7 über die BDE auf eine Datenbank auf einem MSSQL-Server 2019 (v15.0.4326.1) zu. Der Zugriff erfolgt über den MS ODBC-Treiber v18.3 und über die BDE 5.2.0.2 Im Treiber und am Datebank-Eintrag sind bereits "BLOBS TO CACHE" auf 512 und "BLOB SIZE" auf 256 gestellt. Ich habe eine Form, auf der Datenbankinhalte einer Master-Tabelle (Angebotsdaten) angezeigt und editiert werden können. Auf dieser Maske ist auch ein DBGrid, in dem Datensätze aus der Detail-Tabelle (Angebotspositionen) angezeigt und teilw. editiert werden können. In der Detail-Tabelle sind neben den üblichen Preisinformationen (Einzelpreis, Anzahl, Rabatt etc.) und der Positionsnummer auch der Positionstext enthalten. Dieser ist ein VARCHAR mit 2048 Zeichen. Damit dieser potentiell lange Text nicht in der Tabelle angezeigt und editiert werden muss, selektiere ich für die Tabelle die ersten 254 Zeichen - das habe ich sowohl als Datenbank-View als auch direkt als SQL-Statement
Code:
im Code versucht.
CONVERT( VARCHAR(254), LEFT([Text], 254), 0 ) AS [Text_kurz]
Die entsprechende Grid-Spalte ist dann als TStringField definiert und auf ReadOnly gesetzt. Auf der Maske selber ist für die Editierung der Spalte dann noch ein TDBMemo-Feld mit Bezug zu der vollständigen "[Text]"-Spalte... Beim Öffnen eines Angebots wird zuerst die Mastertabelle über ein TQuery ("Head") mit der angeg. Angebots-ID geöffnet und dann die Detail-Datensätze (ebenfalls ein TQuery "Tail") ebenfalls mit der Angebots-ID geöffnet; dann wird auf die letzte Position positioniert ("Tail.Last()"). Soweit funktioniert alles und sowohl im Grid als auch auf der Maske wird der Text / der verkürzte Text angezeigt. Beide Queries sind auf
Code:
eingestellt; beide haben ein UpdateObject gesetzt, in deren SQL-Statements die Pseudo-Spalte [Text_kurz] nicht verwendet wird.
AutoCalcFields=false, CachedUpdates=True, RequestLive=False, UpdateMode=upWhereKeyOnly
Da auf der Maske (und im Masterdatensatz) die Gesamtpreise zu sehen sind, muss ich bei jeder Änderung einer Position oder beim Hinzufügen einer neuen Position die Preise neu zusammenrechnen. Hierzu ist beim Tail-Datensatz eine Event-Methode bei
Code:
hinterlegt.
OnCalcFields
Diese wird aufgerufen und soll dann über eine Schleife die Positionsdatensätze mit
Delphi-Quellcode:
durchlaufen und die Preise zusammenrechnen.
Tail.DisableControls();
Tail.First(); while ( NOT Tail.EOF ) do begin ... Tail.Next(); end; Tai.EnableControls(); Sobald ich im Grid anfange zu editieren und dann das Grid verlassen wird, wird auch die Methode aufgerufen. Blöderweise kommt schon in der o.a. Zeile "Tail.First()" die Exception "Invalid BLOB handle in record buffer" - und zwar auch dann, wenn am Text überhaupt nichts verändert wurde! Aber warum? Beim Einlesen der Datensätze funktioniert doch auch alles? Warum kommt diese Meldung dann nach dem Editieren? Und was kann ich dagegen machen? Oder: kann ich vielleicht die Preise direkt aus den entsprechenden Grid-Spalten auslesen ohne über das TQuery zu wandern? Ich bin etwas ratlos gerade... Übrigens: in meinen Test-Positionen (100 Stück) ist die Text-Länge zw. 130 und 142 Zeichen lang - also weit davon entfernt, abgeschnitten zu werden... |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Also wir haben folgende ähnlich gelagerte fälle gehabt:
Code:
[B]Ungültiges BLOB-Handle im Datensatzpuffer[/B] Februar/2004
Lösung: In einem Datensatz war ein defektes Bild gespeichert. UPDATE PERSONEN SET BILD=NULL
Code:
Mal so zwei Auszüge aus der internen Support Datenbank.
[B]Ungültiges BLOB-Handle im Datensatzpuffer[/B] Februar/2009 (Nicht alle Kunden wollten updaten...also müssen sie unter der BDE leiden)
Es handelt seich dabei um ein BDE Problem. Wenn der MS-SQL Server verwendet wird, werden die BLOB Daten gecached. Die Große des BLOB Caches kann angegeben werden, es ist der Parameter im FTFW Alias BLOB TO CACHE. 8192 wäre zumbeispiel ein sinnvoller Wert, -1 wäre das Maximum. Du bist echt der Beste! BDE->Firedac und Ansi->Unicode Umstellung nicht gemacht... Ganz besonders bewundere ich den BDE-Masochismus! |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
1.) es handelt sich eigentlich nicht um "echte" Binärdaten sondern nur um länger definierte VARCHAR-Spalten. 2.) die Cache-Größe habe ich bereits angepasst - keine Änderung im Verhalten (hatte ich beides oben schon beschrieben... :wink:) Wenn ich die o.a. Positionierung Tail.Last() auf den letzten Tail-Datensatz auskommentiere, kommt der Fehler nicht mehr. Warum das so ist, erschließt sich mir allerdings überhaupt nicht... Zitat:
Im Ernst: ich würde liebend gerne umstellen - aber das ist ein Mammutprojekt (v.a. wg. den verwendeten 3rd-Party Tools/Komponenten), das bisher nicht finanziert wurde... ...die aktuelle Lösung ist, die alten Programme in Win7-VMs laufen zu lassen - damit kommen die Benutzer (leider) prima zurecht --> die Masochisten-Arbeit bleibt also bei der Entwicklung (also mir) hängen... BTW: ich hatte vor einiger Zeit mal versucht, kleinere Teile von den bestehenden Programmen testweise umzustellen (zuerst einmal auf 64-Bit / Unicode) - das hat noch nicht einmal ansatzweise funktionert (es sind auch noch Ur-Ur-Ur-alte, aber sehr wichtige, Programmteile enthalten, die keiner mehr anfassen will, die aus "TurboPascal für DOS"-Zeiten stammen)- und das trotz "Unterstützung" von Embarcadero (die aber eher schlecht war). Auch die Umstellung von BDE-Komponenten auf ADO-Komponenten ist mir bisher hat nicht gelungen - hier v.a. weil ich keine (einfach) funktionierende Unterstützung für lokale Paradox-Datenbanken gefunden habe (die werden als Zwischenspeicher verwendet, um als Reportdaten zu dienen). |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Hallo,
vielleicht hilft ja der Austausch dieses einen DB-Grids durch ein normales TStringGrid. Füllen dann halt per "normaler" Query. Nicht einfach, aber in endlicher Zeit doch lösbar? |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Der Fehler entsteht aber nicht durch das DB-Grid, sondern durch die Menge der Daten. Da gab's schon immer 'nen Flaschenhals.
Statt BDE einfach mal ADO und den ODBC-Treiber von Windows für Paradox probieren (für Paradoxversionen 3.x, 4.x und 5.x)? Der Treiber ist bei meinem Windows 10 von Haus aus dabei (und war er bei älteren Windosen auch schon - führt halt nur ein Schattendasein, da keiner das wirklich zu nutzen scheint.) Der Connectionstring könnte dann in etwa so aussehen:
Code:
Oder 'ne DSN-Datei anlegen, die könnte dann in etwa so aussehen:
Provider=MSDASQL.1;Persist Security Info=False;Data Source=InDerODBCVerwaltungVergebenerName;
Code:
Oder direkt per Verbindungszeichenfolge:
[ODBC]
DRIVER=Microsoft Paradox Driver (*.db ) UID=admin UserCommitSync=Yes Threads=3 SafeTransactions=0 ParadoxUserName=admin ParadoxNetStyle=4.x ParadoxNetPath=C:\Temp PageTimeout=5 MaxScanRows=8 MaxBufferSize=2048 FIL=Paradox 5.X DriverId=538 DefaultDir=C:\Temp CollatingSequence=ASCII
Code:
Driver={Microsoft Paradox Driver (*.db )}; DBQ=c:\temp;DriverID=26
 SQLDriverConnect (Paradox-Treiber) SQLConfigDataSource (Paradox-Treiber)Eventuell mal in der BDE-Configuration mit
Delphi-Quellcode:
probieren, ob das Problem dann weggeht. Eventuell aber auch in der TDataBase-Komponente (soweit sie genutzt wird) bei Params mal
BLOBS TO CACHE = -1
Delphi-Quellcode:
angeben.
BLOBS TO CACHE=-1
Der Fehler tritt halt auf, wenn mehr Blobfelder / Sätze mit Blobfeldern gelesen werden, als der Zahl, die bei BLOBS TO CACHE angegeben wurde, entspricht. Invalid BLOB handle in record bufferEventuell bei der Benutzung der Komponente TQuery die Eigenschaft RequestLive auf True setzen. In der Delphi 7-Hilfe steht da einiges zu, schau mal nach, ob das eine Option sein könnte. (Bin mir nicht ganz sicher, aber der Blobcache wird dann umgangen, so dass das Problem damit eigentlich nicht (mehr) auftreten sollte.) |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Oder mal versuchen die Daten auszutrennen.
Nja, grundsätzlich ist es eh besser so wenig wie möglich Datensätze Daten zu laden. * nicht die ganze Tabelle, sondern nur den/die wichtigen Datensätze (Filter / WHERE) * aktuell "unnötige" Spalten im SELECT weglassen * Spalten mit gleichen/wiederholenden Daten als MasterDetail über ein/mehrere weitere Datasets angängen * auch die Blobs könnte man z.B. via MasterDetail auslagern, vielleicht auch manuell, über einen Ladeknopf Wenn eh kaum gescrollt wird, bzw. die Zeit für das Scrollen nicht so schlimm ist, dann jeweils nur den aktuellen Blob laden vielleicht auch im Hintergrund den/die Blobs in Ruhe in einen Cache nachladen, anstatt sofort ALLES bei der ersten Abfrage. Teilweise können auch die DB-Komponenten selbst Teile eigenständig nachladen. * z.B. den Blob erst laden, wenn drauf zugegriffen wird * oder nicht alle Datensätze laden, sondern immer nur einen Teilbereich, worin man sich grade befindet * oder ... z.B. siehe FetchOptions beim TFDQuery https://docwiki.embarcadero.com/Libr...y.FetchOptionshttps://docwiki.embarcadero.com/Libr...ons_Properties |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
Bei meinen Test-Datensätzen hat die Text-Spalte in den Details eine reale max. Länge von 142 Zeichen. Also kann doch die "Menge der Daten" nicht wirklich ein Problem sein, oder? :wink: Das ganze operiert auf einer MS-SQL Server Datenbank 2019 - der erwähnte Paradox-Treiber wird als Export / "Datenaufbereiter" verwendet, um Reports (Crystal Reports) zu füttern... Ich versuche gerade mal in einem Testprogramm per ADO auf meine Datensätze in der MS-SQLServer Datenbank zuzugreifen... ...so ganz ist mir noch nicht klar, welche Komponenten ich in Delphi dafür verwenden soll Für die BDE habe ich eine TDatabase-Komponente in meinem Programm und jede Menge TQuery / TDataSet-Kombinationen auf meinen Masken - bei den o.a. Master-/Detail-Datensätzen wird auf Datenbank-Views zugegriffen und der Insert/Update/Delete über UpdateSQL-Objekte auf den eigentlichen Tabellen. Für die ADO-Variante habe ich das jetzt als Kombination "TADOConnection", "TADODataset" und "TADOQuery" versucht; testweise auch mal mit den Jedi-Komponenten TJvADOQuery, TJvADODataset Das scheint prinzipiell zu funktionieren - zumindest die "einfache" Auslesung von Daten. Aber wie mache ich das jetzt mit Änderungen? Wo definiere ich die SQL-Statements für INSERT, UPDATE, DELETE? Zitat:
Auf die BDE komplett verzichten zu können, wäre schon schön... :wink: Zitat:
Zitat:
Wie oben bereits erwähnt - wenn ich das Tail.Last() im OnOpen-Handler (oder auch im HeadAfterScroll) weglasse, passiert der Fehler nicht. Wenn ich es mache, kommt der Fehler früher oder später bei Schleifen über die Detail-Datensätze oder einfach beim Scrollen im Grid, das die Detail-Datensätze darstellt... Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Das hat nicht geholfen - der Fehler kam trotzdem. Zitat:
Zitat:
|
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
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. Zuviel geht hier nicht in die Millionen oder zumindest Tausende, sondern in den Bereich von ein paar Dutzend. Genaugenommen eher fast schon lächerlich wenig. Womit kommt denn Crystal Reports zurecht? Alles was "irgendwie" von TDataSet abgeleitet ist, was bei TTable, TQuery, TADOTable, TADOQuery, ... der Fall ist? Dann sollte es auch mit 'ner Memorytable funktionieren, unter Delphi 7 z. B. TClientDataSet. Zitat:
Berechne mal die maximal vorkommende Anzahl von Datensätzen, multipliziere das mit der Anzahl der VarCharspalten (Alle!, unabhängig von der Größe). Die Summe nimmst Du dann mal 1,5 und trägst den Wert bei BLOBS TO CACHE ein. Ist das noch im zulässigen Bereich (wo ist der definiert?) oder klappt das dann damit oder treten andere Seiteneffekte auf? Oder dauert es zumindest länger bis der Fehler auftritt? 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. |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
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:
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:
Ich habe jetzt im BDE-Administrator mal direkt an der ODBC-Datenquelle nachgeschaut - dort steht doch tatsächlich
Delphi-Quellcode:
:shock:
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:
Delphi-Quellcode:
hinzugefügt und beim Master-Datensatz (im AfterScroll) nach dem Öffnen des Detail-Queries ein
BLOBS TO CACHE=-1
Delphi-Quellcode:
wieder eingefügt.
Tail.Last()
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 :thumb: (ich habe aktuell noch einen anderes Problem im Zusammenhang mit der Datenbank - aber das schreibe ich dann in einem neuen Thema...) 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... |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
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:
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:
Zitat:
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. |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
Zitat:
Delphi-Quellcode:
DeleteSQL, InsertSQL und ModifySQL-Statements angeben;
UpdateObject
s.a. https://docwiki.embarcadero.com/Libr...t.UpdateObjectUnd so ein UpdateObject habe ich bei
Delphi-Quellcode:
nicht gefunden...
TADOQuery
EDIT: auch FireDAC hat in seiner Query-Klasse
Delphi-Quellcode:
ein
TFDQuery
Delphi-Quellcode:
; auch die Interbase-Variante hat sowas - nur eben anscheinend die ADO-Variante nicht... :?:
UpdateObject
Zitat:
Zitat:
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:
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:
Da gefällt mir die Möglichkeit, das über MS Paradox ODBC-Treiber zu lösen, wesentlich besser :P |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
Zitat:
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:
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.
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; Zitat:
Zitat:
Zitat:
|
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
[QUOTE=Delphi.Narium;1530533]
Zitat:
Zitat:
--> 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:
Ja, und bei mir ist es sogar noch einfacher, weil die TTable immer nur einen Datensatz hat...
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; Zitat:
Zitat:
|
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
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:
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:
|
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Zitat:
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:
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... |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Ich bin jetzt auf die ZeosLib gestoßen - sieht so auf den ersten Blick vielversprechend aus.
@Delphi.Narium: hast Du mit der vielleicht Erfahrung? Allerdings müsste ich zur Verwendung für mein Szenario auf die Beta-Version v8 aufsetzen (damit auch ODBC-Verbindungen unterstützt werden). Und die bekomme ich bei mir nicht mit / für Delphi 7 übersetzt. Und das Forum dort ist auch ziemlich mühsam... ...da habe ich mich zwar angemeldet und eine entsprechende Frage gestellt - die Frage taucht aber noch nicht auf, weil erst ein Moderator die Frage freigeben muss (das war vor mehr als zwei Tagen). Ich hoffe, das ist nur bei der ersten Frage ein Problem und danach muss nicht jeder einzelne Beitrag über einen Moderator freigeschaltet werden... :roll: Auch deswegen meine Frage: lohnt es sich, sich mit der Library auseinanderzusetzen? |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Hallöle...8-)
Zitat:
Zitat:
Zitat:
https://www.microsoft.com/de-de/down....aspx?id=50402PS: Persönlich hatte ich immer mit ODBC (MSSQL), auch der neueste, meine Probleme. (nicht unterstützte Funktionen = Fehler) :roll: |
AW: "Invalid BLOB handle in record buffer." bei 2. Durchlaufen der Datensätze
Mit meinem Delphi 7 nutzte ich (zuweilen) ZeosLib 7.2.4-stable build at 2018-03-25 11:08:27 (
https://sourceforge.net/p/zeoslib/ne...724-available/).Wenn man dort im Objektinspektor zu eine TZConnection bei Protokoll ado auswählt und dann bei Database auf den ...-Button klickt, wird der Auswahldialog für ADO angezeigt. Dort kann man alles auswählen, was so mit ADO möglich ist. Darunter sind auch die ODBC-Treiber. Für ODBC muss also nicht zwingend die neueste Beta genutzt werden, die Delphi erst ab Tokyo unterstützt. Da hier dann sowieso ADO genutzt wird, reicht es die bei Delphi 7 enthaltenen ADO-Komponenten zu nutzen. Die funktionieren und sind letztlich einfach zu handhaben und auch der Weg des geringsten Widerstandes. Man nutzt einfach das, was sowieso schon (neben der BDE) dabei ist. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 00:35 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz