![]() |
AW: Query = nil nach Query.open...aber nicht immer
Okay, das mit dem lokalen Query werde ich nochmal versuchen... und ja, du hast Recht, das der Aufruf der Funktion nicht aus einem Thread kommt kann man wirklich nicht erkennen...aber dafür hatte ich es ja auch extra hingeschrieben ;-)
FreeAndNil mache ich definitiv auch nicht.. Das die Benutzung der BDE nicht mehr state-of-the-art ist ist mir schon klar! Nein, keine events, die mit dem Query verdrahtet sind weder direkt noch indirekt... alles extrem straight-forward ohne irgendwelche "Schleifchen" dran |
AW: Query = nil nach Query.open...aber nicht immer
Zitat:
Die BDE zickt unter XP schon sehr arg rum, unter neueren Betriebssystemen wird das (vermutlich) kaum besser geworden sein. Die gleichzeitige Funktion mehrerer Programme, die die BDE nutzen, ist unter XP schon häufig nicht möglich, auch eine saubere Beendung der Programme kann scheitern. Den bleiben unbrauchbare Reste der BDE im Speicher, die später dann irgendwie "zuschlagen". BDE-Programme nutzen (soweit ich das mitbekommen habe) einen gemeinsamen Speicherbereich. Wenn das nicht sauber funktioniert, dann kann da jeder beliebige "Müll" im Arbeitsspeicher entstehen. Warum nicht auch mal 'ne zerschossenen Query? Je nach Datenbank kann dieser Quellcode mit der BDE auch scheitern:
Delphi-Quellcode:
query1.RecordCount zählt die Sätze, indem es durch die Datenmenge läuft. Ist der letzte Satz erreicht, enthält RecordCount die Anzahl der Sätze. Der Datensatzzeiger der Query steht dann auf dem letzten Satz.
if query1.RecordCount > 0 then // rumms.....
begin if not firstrecord then query1.last; value := query1.fieldbyname(Field).AsString; end; Hier wäre eventuell ein
Delphi-Quellcode:
sinnvoller.
begin
if firstrecord then query1.First else query1.last; Hierbei möchte ich nicht ausschließen, dass, abhängig vom Dateninhalt der Abfrage, beim Durchlaufen der Datenmenge, um RecordCount zu ermitteln, irgendwas im Speicher "zerschossen" wird. Um festzustellen, ob überhaupt etwas in der Ergebnismenge ist, könnte eventuell auch sowas reichen:
Delphi-Quellcode:
if not query1.EoF then
begin if firstrecord then query1.First else query1.last; value := query1.fieldbyname(Field).AsString; end; |
AW: Query = nil nach Query.open...aber nicht immer
Falls es mit der BDE nicht klapp, schau bitte mal, ob Du Dir über die ODBC einen Treiber für Paradox einrichten kannst, da sollte eigentlich einer von Microsoft vorhanden sein.
Wenn das geht, könntest Du statt der BDE eventuell ADO-Componenten nutzen. |
AW: Query = nil nach Query.open...aber nicht immer
Versuch es mal mit
Delphi-Quellcode:
ich meine mich zu erinnern, daß ich mal vor die selbe wand gelaufen bin.
self.Query1
Gruß K-H |
AW: Query = nil nach Query.open...aber nicht immer
Zitat:
Mit ADO und ODBC kommt ja auch u.U. die BDE wieder ins Spiel da der MS-Treiber (Access-JET-Treiber) bei installierter BDE diesen verwendet. |
AW: Query = nil nach Query.open...aber nicht immer
Ich gehe davon aus das du bewusst oder unbewusst dein Quere Objekt freigibst.
Findest du da keine Stelle die dir Spanisch vorkommt, dann hast du ein anderes Problem :-D |
AW: Query = nil nach Query.open...aber nicht immer
Zitat:
Ich würde auf Recordcount nicht abfragen, dass kann nur in die Hose gehen. Wie wäre es mit....
Delphi-Quellcode:
function TDataModule1.OpenCommand(query : string;field:string;var value: string; firstrecord : boolean = True) : boolean;
var aQuery : TQuery; begin Result := False; value := ''; aQuery := TQuery.Create(nil); try try aQuery.Database := XYZ aQuery.sql.text := query; aQuery.Open; if not aQuery.Eof then begin if not firstrecord then aQuery.last; value := aQuery.fieldbyname(Field).AsString; Result := True; end else begin Value := 'Keine Ergebnismenge!' end; aQuery.Close; except On e.Exception ..... end; finally aQuery.Free end; end; |
AW: Query = nil nach Query.open...aber nicht immer
da sind ja ein paarinteressante Tips bei...Danke euch allen erstmal!
Werde mal testen und dann berichten.... |
AW: Query = nil nach Query.open...aber nicht immer
Wo wird Query1 deklariert?
Wenn Du einen Buffer-Overrun hast, dann kann Query1 plötzlich 'zerstört' sein. Beispiel
Delphi-Quellcode:
Das geht nur, wenn RangeChecks ausgeschaltet sind (sind sie aber per Default).
Var
EinArray : Array [0..10] of Byte; Query1 : TQuery; i : integer; begin Query1 := TQuery.Create; for i:=0 to 14 do EinArray[i] := 0; // Query1 ist Nil; Obskure Fehler dieser Art sollten sich mit FastMem finden lassen. |
AW: Query = nil nach Query.open...aber nicht immer
Zitat:
Microsoft hat(te) einen eigenen Treiber für Paradox, der per ADO auch dann funktioniert, wenn keine BDE installiert ist. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:59 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