Bereichsfilter bei SQL-Datenbank vs. Bereichsfilter CSide

Wenn man in CSide ein Textfeld auf A*..B* filtert, wird alles, was mit A beginnt, nicht angezeigt, aber alles, was mit B beginnt.

Wenn man in einer SQL-Datenbank dasselbe tut, wird alles, was mit B beginnt, nicht angezeigt, aber alles, was mit A beginnt.

Erwartet hätte ich eigentlich, dass immer alles, was mit A oder B beginnt, angezeigt wird. Wenn man ein Datumsfeld auf 01.01.12..31.12.12 filtert, werden ja auch die Datensätze angezeigt, die in diesem Datumsfeld den 01.01.12 oder den 31.12.12 stehen haben.


Kann das jemand evtl. logisch erklären?

Ist die SQL Datenbank "case sesnitive" eingestellt?

Was bringt ein Filter wie @A*..B* ?

Ja, ist eingestellt (Codepage 51).

Man kann mit so einem Filter anhand der Anfangsbuchstaben der Nachnamen der Kontakte diese den Sachbearbeitern zuordnen :)

Für mein Verständnis hängt dies mit Deinen Wildcard zusammen. Im Grunde ladet die Abfrage Textfeld >= A* und Textfeld <=B*. Wärend Du bei der Datumsabfrage 01.01.12..31.12.12 einen klar definierten Endpunkt hast, ist dies bei B* nicht der Fall. Das Wildcardzeichen kann für alle nachfolgenden Felder stehen oder für keines. Und dies ist vermutlich der ausschlaggebende Punkt. B* kann auch nur für B stehen und somit wäre der Filter korrekt. Aber da Dir dieses Verhalten bekannt ist, kannst Du ja jetzt Deine Fileter dem entsprechend setzen, indem Du den Filter A*..Bz* verwendest oder gleich A*..C*.

Aber da Dir dieses Verhalten bekannt ist, kannst Du ja jetzt Deine Fileter dem entsprechend setzen, indem Du den Filter A*..Bz* verwendest oder gleich A*..C*.

Bei meinen Tests hier ist es noch schlimmer. Hier (SQL) ergibt der Filter A*..B* nicht nur jene, die mit A beginnen, sondern es kommen auch noch jene mit "B" dazu, die zB "B + B Milch", "B&B Milch" heißen. Jene, die mit A beginnen und so sind ("A + A Milch", A&A Milch"), sind dafür (ebenso wie alle anderen mit B) nicht dabei.

Einzig '@A*|@B*' liefert anscheinend das gewünschte Ergebnis.

Edit: das verhält sich auf der 2009er-SQL-Cronus auch so (CC/RTC).

Müsste ">=a&<c" nicht das gewünschte Ergebnis liefern?
Mit einem kleinen Defekt geht doch auch "a..c".

Wildcards braucht man hier doch nicht.

mfg,
winfy

Stimmt .. oder so