Query = nil nach Query.open...aber nicht immer

[noisy_master]

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

[nahpets]

Zitat von DeddyH:

Zeig doch mal Code.

und nenne uns das Betriebssystem.

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:

 if query1.RecordCount > 0 then // rumms.....
  begin
    if not firstrecord then
      query1.last;
    value := query1.fieldbyname(Field).AsString;
  end;

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.

Hier wäre eventuell ein

Delphi-Quellcode:

begin
    if firstrecord then query1.First else    query1.last;

sinnvoller.

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;

[nahpets]

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.

[p80286]

Versuch es mal mit self.Query1 ich meine mich zu erinnern, daß ich mal vor die selbe wand gelaufen bin.

Gruß
K-H

[Bernhard Geyer]

Zitat von nahpets:

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.

Es gibt doch auch native Delphi-Komponenten die ohne BDE auf Paradox zugreifen können.
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.

[HeZa]

Ich gehe davon aus das du bewusst oder unbewusst dein Quere Objekt freigibst.

1. Das könntest du wie folgt prüfen:
2. Übersetze dein Programm mit Debug DCUs
3. Setze einen Breakpoint im Destructor der Query
4. Wenn dein Programm an der Stelle anhält analysierst du den Aufrufstack

.

Findest du da keine Stelle die dir Spanisch vorkommt, dann hast du ein anderes Problem

[ibp]

Zitat von noisy_master:

nicht hübsch und nicht spannend:

Delphi-Quellcode:

function TDataModule1.OpenCommand(query : string;field:string;var value: string; firstrecord : boolean = True) : boolean;
begin
  query1.close;
  query1.sql.clear;
  query1.sql.add(query);                          // hier ist es noch ok
try
  value := '';
  query1.Open;                                    // hier auch noch
  if query1.RecordCount > 0 then                  // rumms.....
  begin
    if not firstrecord then
      query1.last;
    value := query1.fieldbyname(Field).AsString;
  end;
  query1.close;
  result := true;
except
  query1.close;
  result := false;
end;
end;

aber wie schon gesagt: es funktioniert nicht prinzipiell nicht sondern nur manchmal!

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;

[noisy_master]

da sind ja ein paarinteressante Tips bei...Danke euch allen erstmal!
Werde mal testen und dann berichten....

[Dejan Vu]

Wo wird Query1 deklariert?
Wenn Du einen Buffer-Overrun hast, dann kann Query1 plötzlich 'zerstört' sein. Beispiel

Delphi-Quellcode:

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;

Das geht nur, wenn RangeChecks ausgeschaltet sind (sind sie aber per Default).

Obskure Fehler dieser Art sollten sich mit FastMem finden lassen.

[nahpets]

Zitat von Bernhard Geyer:

Zitat von nahpets:

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.

Es gibt doch auch native Delphi-Komponenten die ohne BDE auf Paradox zugreifen können.
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.

Kenne nur eine Komponente, die auf dBase-Dateien zugreifen kann, sie kann aber kein SQL.

Microsoft hat(te) einen eigenen Treiber für Paradox, der per ADO auch dann funktioniert, wenn keine BDE installiert ist.