Dataset.Filter für optionale Felder

[Stephan Schneider]

Umg.: Delphi 6 Ent. UP2, BDE 5.2.0.2

Wenn ich bei einer TTable oder TQuery die Filter-Eigenschaft für ein optionales Feld mit dem Wert Null setze, dann erfolgt diese Sichteinschränkung nur bei Paradox, bei z.B. MSSQL nicht.

Beispiel: Die Tabelle hat folgende Struktur

ID, integer, Primäschlüssel<br>
...<br>
ForeignKey, integer, Fremdschlüssel, optional

Mittels einer Methode werden all diejenigen ForeignKeys ermittelt, die sichtbar sein sollen. Als Ergebnis liefert diese Methode z.B. die Werte 1, 2, 4, 5. Aus Gründen der Anwendungslogik sollen all diese Datensätze angezeigt werden, die entweder diesen Werten entsprechen oder Null (d.h. aufgrund der Optionalität nicht gesetzt) sind.

Mein dynamisch zusammengesetzter Filter-String sieht so aus:

Filter := 'ForeignKey=1 or ForeignKey=2 or ForeignKey=4 or ForeignKey=5 or ForeignKey is null'

Bei Paradox werden auch die ForeignKey=null Datensätze angezeigt, bei MSSQL nicht.

[M.Pannier]

Hallo!<br>
ich hab noch nie mit MSSQL gearbeitet, aber vielleicht ist er etwas anspruchsvoller als Paradox. Versuch einfach mal den Filter in Klammern zu setzen. '(ForeignKey=1) or (ForeignKey=2). Eine 2. Variante wäre null nicht mit 'is null' sondern mit '=null' abzufragen. <br>
Vielleicht hilfts.<br>
Gruß M.Pannie

[Stephan Schneider]

Danke für deine Antwort. Leider war sie nicht von Erfolg gekrönt. Sowohl das Setzen in Klammern, wie auch das Ändern in = null haben keinerlei Auswirkungen. MSSQL zeigt die "null-records" nicht an, Paradox schon.

Stepha

[Jochen Reichenberg]

Funktioniert es denn, wenn Du das mal nicht über den Filter sondern direkt im Select-Statement machst

[Stephan Schneider]

@Jochen: Dies muss ich noch ausprobieren. Sollte es klappen, dann wird dies aber das grundsätzliches Problem nicht lösen. Diese Anwendung läuft sowohl unter Paradox, Oracle und MSSQL. Im Prinzip funktioniert alles. Natürlich ist so eine "eierlegende Wollmichsau" nicht unbedingt das Wahre, aber ändern kann ich diese über Jahre gewachsene Tatsache auch nicht mehr. Innerhalb der Anwendung wird ein Mix aus TTable und TQuery verwendet, wie gesagt, im Prinzip nicht schlecht. Aber es gibt Tabellen, da wird mittels TTable darauf zugegriffen. Hier habe ich dann schlichtweg die Möglichkeit eines SQL-SELECTs nicht.

Da aber bei TQuery äußerst komplexe SQL-Statements zusammengebaut werden, die ihrerseits eine Einschränkung mittels WHERE beinhalten, gehe ich nun einfach davon aus, dass eine Erweiterung der WHERE-Klausel erfolgreich ist. Aber was tun bei TTable...

Stepha

[Andreas Kosch]

Hallo,

beim MS SQL Server besteht die Möglichkeit, sich über den aktivierten <i>Profiler</i> alle die SQL-Anweisungen mitprotokollieren zu lassen, die das TTable+IDAPI-Gespann aus der Eigenschafts-Konfiguration in SQL-Anweisungen umsetzt. Welche Anweisung trift beim MS SQL Server ein, wenn das o.g. Filter für TTable aktiviert wird?

&gt;Aber was tun bei TTable...

Hier hilft nur Experimentieren (Umstellen der Filterbedingung)

[Stephan Schneider]

@Andreas Kosch

Die Tabelle Satzaufbau soll anhand des Fremdschlüssels SachgebietID eingeschränkt werden. Ich habe mir mal die vom Profiler protokollierten Einträge angesehen und die für die Sichteinschränkung relevante Zeile lautet:

exec sp_executesql N'SELECT "ID" ,"Beschreibung" ,"SachgebietID" ,FROM "Satzaufbau" WHERE ((("SachgebietID" = @P1) OR ("SachgebietID" = @P2)) OR 0 = 1 )', N'@P1 int,@P2 int', 2, 3

Der generierte FilterString sieht so aus (unter Dataset.Filter gesetzt):

(SachgebietID = 2) OR (SachgebietID = 3) OR (SachgebietID is null)

Unter Paradox werden die Einträge angezeigt, die in diesem Feld den Wert 2 oder 3 haben oder die leer (null) sind. So wie's sein sollte. Unter MSSQL kommen nur die 2er und 3er durch. Was soll eigentlich der letzte Term "0=1"

[Andreas Kosch]

Hallo,

anscheinend übersetzt der SQLLinks-Treiber der BDE die SQL-Anweisung "<i>(SachgebietID is null)</i>" in das gründlich missratene Gegenstück "<i>OR 0 = 1</i>". Es ist dann klar, dass der MS SQL Server keine Treffer findet, denn bereits die BDE schickt unkorrekte SQLs zum Server (der Profiler zeigt nur das an, was beim Server eintrifft).

Was kommt beim Profiler an, wenn der Filterstring nur "(SachgebietID is null)" lautet?

Was passiert, wenn "(SachgebietID is null)" ganz an den Anfang der Filterbedingung verschoben wird

[Stephan Schneider]

Der SQLLinks-Treiber der BDE scheint hierbei einen Fehler zu machen.

Setze ich <i>SachgebietID is null</i> an den Anfang, ändert sich im Prinzip nichts am Eintrag im Profiler, nur, dass der Ausdruck 0=1 an den Anfang plaziert wird.

Reduziere ich den Filterausdruck auf <i>SachgebietID is null</i> und lasse die anderen Einschränkungen weg, dann erscheint
exec sp_executesql N'SELECT "ID" ,"Beschreibung" ,"SachgebietID" ,FROM "Satzaufbau" WHERE (("SachgebietID" = @P1))', N'@P1 int,0

Wie zu sehen ist, wird der Ausdruck <i>is null</i> in diesem Fall mit dem numerischen Wert 0 parametriert. Die Folge: Leeres Gri

[Andreas Kosch]

Hallo,

was dann wieder die Theorie bestätigt, dass das Ganze nur so stark ist wie das schwächste Teilstück. Jede Simulation hat Nebenwirkungen (Übersetzungsfehler) und TTable ist nur unter bestimmten Voraussetzungen bei SQL-Datenbanken ein gleichwertiger Partner

[Stephan Schneider]

@Andreas Kosch: Da muss ich ihnen recht geben. Wird die Filter-Eigenschaft einer TQuery-Komponente gesetzt, dann klappt's