Entwickler-Ecke

Datenbanken - ADOConnection beeinflusst Berechnungen (extended = double)


Der Bastler - Mi 09.07.08 11:04
Titel: ADOConnection beeinflusst Berechnungen (extended = double)
Ich bin fast verzweifelt und habe überall im meinem Berechnungsprogramm nach einem Fehler gesucht, bis mir aufgefallen ist, dass nach einer ADOConnection Extended plötzlich auf Double gerundet wird und zwar im komplettem Programm auch in völlig anderen Unit's.

Das kann doch eingentlich nicht sein, oder?

Wo liegt mein Fehler, hat vieleicht jemand von euch eine Idee?

Ich habe das ganze Problem in einer Procedure zusammengefasst:


Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
procedure WasIstHierLos;
var
  ADOConnection: TADOConnection;
  ExtVal1, ExtVal2, ResExtVal: Extended;
  ResDoubleVal: Double;
begin
  ExtVal1 := 0.2;
  ExtVal2 := 0.5;

  ResDoubleVal := ExtVal1 / ExtVal2;
  ResExtVal := ExtVal1 / ExtVal2;
  if ResDoubleVal = ResExtVal then      { Hier ist ResDoubleVal <> ResExtVal ! }
    Exit;

  try
    ADOConnection := TADOConnection.Create(NIL);
    ADOConnection.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+
          'Test.mdb;Mode=ReadWrite|Share Deny None;Persist Security Info=False';
    ADOConnection.Open;
    ADOConnection.Close;
    FreeAndNIL(ADOConnection);

    ResDoubleVal := ExtVal1 / ExtVal2;
    ResExtVal := ExtVal1 / ExtVal2;
    if ResDoubleVal = ResExtVal then     { Hier ist ResDoubleVal = ResExtVal ! }
      Exit;

    // Die Stelle wird nie mehr erreicht, aber warum ?
    // ...

  except
    //...
  end;
end;


Moderiert von user profile iconChristian S.: Delphi-Tags hinzugefügt


mkinzler - Mi 09.07.08 11:34

Man sollte Floatwerte nie auf Gleichheit überprüfen.


alzaimar - Mi 09.07.08 12:13

Kann ich mit einer SQL-Serververbindung nicht nachvollziehen, aber sehr wohl mit der Jet-Engine. Vermutlich verändert die irgendwelche FPU-Einstellungen. Blöd.

Ansonsten halte es wie mkinzler schon sagte: Floating Point Werte nie auf Gleichheit prüfen.


Agawain - Mi 09.07.08 13:23

hi,

liegt wohl eher daran, dass msaccess kein extended kennt, sondern nur double.


alzaimar - Mi 09.07.08 13:34

Jo, und wieso funktioniert dann hinterher der DELPHI-Code nicht mehr (der code hat ja nix mit Access zu tun)


mkinzler - Mi 09.07.08 13:51

Das könnte aber der Grund sein, das die beiden Werte verschieden sind. Deshalb nie direkt auf leichheit prüfen.


alzaimar - Mi 09.07.08 14:19

Wieso sollte die kurzzeitige Aktivierung des JET-Moduls zu einer Veränderung der Rechenergebnisse führen?

Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
Var
  a,b, c1, c2, diff : Extended;

Begin
  a := 0.2;
  b := 0.5;
  c1 := a/b;
  CreateOpenAndDestroyADOConnectionWithJETModule;
  c2 := a/b;

  diff := c1-c2;
  Showmessage(FloatToStr(diff));
End;

Es sollte doch IMMER 0 rauskommen, oder? Egal was die Methode 'CreateOpen...' macht.
Hier kommt aber -2,219E-17 heraus, also verändert die Tatsache, das das Jet-modul kurzzeitig aktiviert wurde, das Verhalten der FPU. Wenn das normal oder zu erwarten ist, dann weiss ich auch nicht. Wenn ich nun eine Engine Aktiviere, die überhaupt nicht mit Zahlen klarkommt, dann ... äh... kann man hinterher auch nicht mehr rechnen???