DBSetFilter() und Datentypen ...

[brandelh]

Hallo,

ich mache gerade Auswertungslisten mit DBSetFilter() auf eine ältere Datei .... z.B.

Code: Alles auswählen

LI->(dbSetFilter({|| field->VK=629 .and. (field->VA==31 .or. field->VA==40) .and. field->plausi#"A" }))
LI->(dbgotop())

dabei habe ich übersehen, dass die Felder in der DBF VK = Char mit 5 und VA Char mit 3 Stellen sind.

man beachte ... field->VK=629 etc. und dennoch kommen die Ergebnisse ohne Fehler wie erwartet
Eigentlich hätte doch da ein Fehler auftauchen müssen denn "629" ist nun mal nicht == 629 oder bin ich jetzt total blind geworden ...

Natürlich geht auch die verbesserte Version ohne Fehler ...

Code: Alles auswählen

LI->(dbSetFilter({|| field->VK="629" .and. (field->VA=="31" .or. field->VA=="40") .and. field->plausi#"A" }))
LI->(dbgotop())

aber das ist doch auch nicht richtig oder ? Schließlich sind in der DBF "629 " und "40 " gespeichert

Das hätte ich jetzt nicht erwartet

[Tom]

Seltsam. Bei mir feuert brav ein Laufzeitfehler, wenn ich das tue. Kann es sein, dass Du Datentypenverwechslungen irgendwo abfängst?

[brandelh]

Hi,

nein, ich nutze ein geändertes EXEL2.PRG um die Ergebnisse in Excel Tabellen zu kopieren.
Nun habe ich ganz neu dieses kleine Programm generiert ...

Code: Alles auswählen

#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Inkey.ch"
#include "DBFDBE.CH"
#include "NTXDBE.CH"

#include "FOXDBE.CH"
#include "CDXDBE.CH"

#include "directry.CH"

procedure main()

   set alternate to test_log.txt
   set alternate on

   use uv_diag
   if neterr()
      ? "NETERR"
      quit
   endif
   aeval(DbStruct(),{|aZ| qout(aZ)})
   for x := 1 to 10
       ? x,vk, va, plausi,we_key
   next
   cls

   ? "Filter setzen"
   set filter to vk=690
   go top
   for x := 1 to 10
       ? x, vk, va, plausi,we_key
   next
return

und wie man an dieser LOG Datei sieht, gibt es keine Fehlermeldung und die Ergebnisse stimmen (hier gelöscht):

Code: Alles auswählen

{VK, C,          5,          0}
{VA, C,          4,          0}
{PLAUSI, C,          1,          0}
{WE_KEY, C,          9,          0}
{KATEGORIE, C,          1,          0}
{VK_TXT, C,        150,          0}
{VA_TXT, C,        150,          0}
{WE_TXT, C,        150,          0}
{SAVE_DATUM, D,          8,          0}
         1 ...   ..   .          
         2 ...   ..   .
         3 ...   ..   .
         4 ...   ..   .
         5 ...   ..   .
         6 ...   ..   .
         7 ...   ..   .
         8 ...   ..   .
         9 ...   ..   .
        10 ...   ..   .
Filter setzen
         1 ...   ..   .          
         2 ...   ..   .
         3 ...   ..   .
         4 ...   ..   .
         5 ...   ..   .
         6 ...   ..   .
         7 ...   ..   .
         8 ...   ..   .
         9 ...   ..   .
        10 ...   ..   . 

PS: zuerst hatte ich nichts gefunden, da das Beispiel 690 nicht existiert hat

[brandelh]

eben habe ich gedacht es könnte an einer der getauschten DLL liegen ...

Aber mein Beispiel reagiert genauso mit 1.82 und 1.90.331 bzw. 1.90.355

eigentlich dachte ich, dass ich mich auskenne

[Dieter]

Hallo Hubert,
in deinem Beispiel fehlt das Skip in der Schleife. Der Filter wirkt sich also immer nur auf den ersten gefundenen Datensatz aus.
Es sieht in der Tat so aus, dass eine Typprüfung in der Filterbedingung nicht stattfindet. Der Filter ist so intelligent, dass er Zeichen in Zahlen umwandeln kann. Getestet habe ich das gerade mit

Code: Alles auswählen

set filter to fin->nBetrag > "200000"

Ich war überrascht, dass das geht.

[brandelh]

Hallo Hubert,
in deinem Beispiel fehlt das Skip in der Schleife.

in diesem Beispiel hab ich das doch glatt vergessen dennoch fand ich es höchst seltsam, dass ausgerechnet beim Filter keine Typprüfung stattfindet ... wobei TOM sagt er hätte eine

[Dieter]

Hallo Hubert,

Die "Intelligenz" der Filterbedingungen ist in der Dokumentation nicht beschrieben. Vielleicht ist diese auch dafür verantwortlich, dass die Set Filter-Befehle oft zu Geschwindigkeitsproblemen führen, welche hier im Forum schon öfter diskutiert worden sind.

[Tom]

Hallo, Hubert.

Ich habe das nicht mit einem direkten Ausdruck im Programm, sondern über eine Funktionalität in meinem Datenbank-Repository-Editor ausprobiert. Dort kann man einen Filter setzen, also eine Eingabe wie [NR = 400] tätigen. Dann folgt eine Sequenz, vor der der ErrorBlock auf Break() gesetzt wird. In der Sequenz setze ich den Filter über ein Makro. Wenn ein Fehler erfolgt, nörgelt das Programm, dass der Ausdruck verkehrt war. Und genau das geschieht, wenn ich einen Filter auf [NR = 400] setze und "NR" ein alphanumerisches Feld ist. Das Fehlersystem feuert also.

[brandelh]

Hallo Tom,

dann müsste ja in der ErrorSys eine Korrektur erfolgen oder habe ich dich falsch verstanden ?

[Tom]

Hallo, Hubert.

Nein. Ich fange das Fehlersystem mit

Code: Alles auswählen

ErrorBlock( {|e| lOk := .F.,Break(e)} )

vor der SEQUENCE ab. Im RECOVER-Bereich melde ich dann den vermeintlichen Syntaxfehler in der Filterbedingung. Das arbeitet ganz wunderbar - und bei einem numerischen Filter auf ein alphanumerisches Feld feuert der Errorblock.