Boolesche "ODER"-Verknüpfungen als Abfrage

[MzKlMu]

Hallo,
die Joins sind alle überflüssig, oder siehst Du in meiner Abfrage weitere Tabellen für eine Beziehung? Die Nebentabellen kommen in der Abfrage für den Sperrvermerk nur in der Formel vor.

[C4RL0]

So jetzt, ich habe den Code exakt wie in Deinem Beispiel eingegeben (die Namen natürlich entsprechend verändert)

Code [Auswählen] Erweitern

SELECT Bingodata.idprozessauftragsnummer, IIf(DSum("blnStatus","IndicationData_Abweich","lngAuftragsNr = " & [lngAuftragsNr])+DSum("blnStatus","IndicationData_CAPA","lngAuftragsNr = " & [lngAuftragsNr])+DSum("blnStatus","IndicationData_CC","lngAuftragsNr = " & [lngAuftragsNr])=0,"",True) AS Sperrvermerk
FROM Bingodata;

Jetzt fragt mich der Hund per Popup nach der lngAuftragsNr, wenn ich die Abfrage starte.

[MzKlMu]

Hallo,
lade die DB mal hoch, mit Spieldaten, gezippt in Access2003.

[C4RL0]

Das Ding hat gezippt noch über 8 mb, ich fürchte das wird schwer

[C4RL0]

Ok, scheinbar musste ich den Spaltennamen der Haupt- und nicht der Nebentabelle nehmen:

Code [Auswählen] Erweitern

SELECT Bingodata.idprozessauftragsnummer, IIf(DSum("blnStatus","IndicationData_Abweich","lngAuftragsNr = " & [idprozessauftragsnummer])+DSum("blnStatus","IndicationData_CAPA","lngAuftragsNr = " & [idprozessauftragsnummer])+DSum("blnStatus","IndicationData_CC","lngAuftragsNr = " & [idprozessauftragsnummer])=0,"frei","gesperrt") AS Sperrvermerk
FROM Bingodata;

Jetzt heißt der Fehler "Datentypen in Kriterienausdruck unverträglich"... nur welcher, sagt er nicht.

[ebs17]

... nur wenn ich zu diesem Zeitpunkt das Datenmodell wieder infrage stelle, fange ich mit der Anwendung komplett von vorne an. Das ohne ein Mehr an Wissen meinerseits, bringts nicht.

Als Wissen solltest Du auf jeden Fall mitnehmen, dass sich gescheite und performante Abfragen i.d.R. nur bei einem passenden Datenmodell erstellen lassen - immerhin benötigt der Sportwagen SQL zum Entfalten seiner erheblichen Fähigkeiten eine passende Rennbahn, bereitet u.a. durch gute Datenmodellierung und Normalisierung.
Und Du darfst die Gewissheit mitnehmen, dass ein späteres Neuanfangen noch aufwändiger und schmerzlicher sein wird.

Zu der Eingangsfrage:

Code [Auswählen] Erweitern

SELECT
   T.ArtNr,
   EXISTS (SELECT Null FROM TabelleU1 U WHERE U.ArtNr = T.ArtNr AND U.Gesperrt = True)
   +
   EXISTS (SELECT Null FROM TabelleU2 U WHERE U.ArtNr = T.ArtNr AND U.Gesperrt = True)
   + ...
   AS Gesperrt
FROM
   TabelleH T

[C4RL0]

Wir sind auf dem richtigen Weg, danke, ebs17. Das, worüber Access jetzt noch meckert, ist wohl die Summierung mittels "+", allerdings kann man die Fehlermeldung nicht vollständig lesen:

"in Abfrageausdruck ...[SQL string]" steht dort nur.

Ersetze ich die "+" durch "&" erhalte ich als Ergebnis meine 6 Checkboxen-Stati, natürlich leider als verketteten String "-1 0 -1 -1 0 0".

Oder liege ich falsch mit meiner Vermutung (Summe)?

[ebs17]

Zeige Deine vollständige SQL-Anweisung, dann bitte lesbar formatiert: SQL Formatter

Der verwendete Lösungsansatz (weg von den grässlichen Domänenaggregatfunktionen):
Ein EXISTS-Ausdruck ergibt True (-1) oder False (0). Diese Zahlen sollte man addieren (+) können. Ist das Ergebnis < 0, so liegt mindestens eine Sperrung vor.
Eine Verkettung (&) ist da nicht so sinnvoll.

Testausdruck:

Code [Auswählen] Erweitern

SELECT True + False + True + False as X

MfGA
ebs

[C4RL0]

Hi,

im Moment sieht es wie folgt aus (zum Testen auf 3 Untertabellen reduziert):

Code [Auswählen] Erweitern

SELECT   Bingodata.idprozessauftragsnummer,
         EXISTS
         (SELECT NULL
         FROM    IndicationData_Abweich U
         WHERE   U.lngAuftragsNr = Bingodata.idprozessauftragsnummer
         AND     U.blnStatus     = True
         )
         + EXISTS
         (SELECT NULL
         FROM    IndicationData_CAPA U
         WHERE   U.lngAuftragsNr = Bingodata.idprozessauftragsnummer
         AND     U.blnStatus     = True
         )
         + EXISTS
         (SELECT NULL
         FROM    IndicationData_CC U
         WHERE   U.lngAuftragsNr = Bingodata.idprozessauftragsnummer
         AND     U.blnStatus     = True
         )
         AS Gesperrt
FROM     Bingodata
WHERE    (
                  (
                           (
                                    Bingodata.idprozessauftragsnummer
                           )
                           NOT LIKE "*44?????"
                  )
         )
ORDER BY Bingodata.idprozessauftragsnummer DESC;

[ebs17]

Diese Anweisung erzeugt den gleichen Fehler und funktioniert mit "&"? Da bin ich ratlos.

Ggf. müsste man testen mit einzelnen Teilausdrücken sowie mit verringerter Datenmenge (wenn Fehler aus Daten herrührt), und natürlich sollte man Schreibfehler bei den Bezeichnungen ausschließen.

Nebenbei:

Code [Auswählen] Erweitern

WHERE Bingodata.idprozessauftragsnummer NOT LIKE "*44?????"Ein solches Kriterium unterstützt nicht die Verwendung eines Index auf die ID und bedeutet den Verzicht auf erhebliche Performance.
Sehr wahrscheinlich wäre hier auch ein zusätzlicher Normalisierungsschritt angeraten:

Code [Auswählen] Erweitern

*44?????
=> Feld1: Inhalt von *
=> Feld2: 44       ' Kennzahl?
=> Feld3: ?????    ' laufende Nummer?

WHERE Feld2 = 44



MfGA
ebs

[C4RL0]

Ggf. müsste man testen mit einzelnen Teilausdrücken sowie mit verringerter Datenmenge (wenn Fehler aus Daten herrührt), und natürlich sollte man Schreibfehler bei den Bezeichnungen ausschließen.

Wenn ich den Ausdruck "exists" weglasse, nimmt Access auch den "+" Operator, natürlich kommt kein brauchbares Ergebnis raus, was mich aber zu der Frage drängt, ob man "EXISTS"-Ergebnbisse überhaupt so summieren kann?

Ein solches Kriterium unterstützt nicht die Verwendung eines Index auf die ID und bedeutet den Verzicht auf erhebliche Performance.

Wie ändere ich das denn, damit es performanter wird? Die ProzessID ist eine mehr oder weniger beliebige 7-stellige Nummer, ich brauche für diesen Zweck nur die nicht, die mit 44 beginnen.

[ebs17]

was mich aber zu der Frage drängt, ob man "EXISTS"-Ergebnbisse überhaupt so summieren kann?

Das drängt mich zu der Frage, ob Du die obigen Beiträge vollständig gelesen hast. Du kannst gerne noch mal eine Ehrenrunde drehen.

beliebige 7-stellige Nummer, ich brauche für diesen Zweck nur die nicht, die mit 44 beginnen

In einer beliebigen Zahl ist es uninteressant, ob da bestimmte Ziffern an bestimmten Stellen vorkommen. Man muss schon erst seine Aufgabe begreifen, ehe man sie lösen kann.

Wie ändere ich das denn ...

Wie gesagt: Im Idealfall einen zusätzlicher Normalisierungsschritt ausführen.

Alternativ: Zahlen kann man auch in der Programmierung als Zahlen behandeln, da ist keine Textverarbeitung notwendig:

Code [Auswählen] Erweitern

WHERE ID < 4400000 OR ID >= 4500000

MfGA
ebs

[C4RL0]

was mich aber zu der Frage drängt, ob man "EXISTS"-Ergebnbisse überhaupt so summieren kann?

Das drängt mich zu der Frage, ob Du die obigen Beiträge vollständig gelesen hast. Du kannst gerne noch mal eine Ehrenrunde drehen....

Ja, kein Grund garstig zu werden, mein Access verhält sich nicht anders, je öfter ich hier Ehrenrunden drehe, es lehnt die Kombi "EXISTS" und "+" in dieser Konstellation einfach ab. Ich habe mir inzwischen mit dem "OR" Operator an Stelle des "+" geholfen, also die EXISTS allesamt mit OR verknüpft.

Da meine Eingangsfrage hiermit gelöst ist, markiere ich den Thread dementsprechend. An dieser Stelle ein herzliches "Danke" an MzKlMu und ebs17!

beliebige 7-stellige Nummer, ich brauche für diesen Zweck nur die nicht, die mit 44 beginnen

In einer beliebigen Zahl ist es uninteressant, ob da bestimmte Ziffern an bestimmten Stellen vorkommen. Man muss schon erst seine Aufgabe begreifen, ehe man sie lösen kann.....

Hilfe in der Form des kategorischen Imperativs ist selten wirklich hilfreich. Und nein, es ist nicht uninteressant, welche Ziffern an welchen Stellen vorkommen, da die Ziffer nach einem bestimmten System aufgebaut ist. Das alles passiert jedoch im SAP, und damit gänzlich unerreichbar für meine Access-Anwendung und auch für etwaige Normalisierungsbemühungen. Lokal gesehen ist es daher eine beliebige Zahl, global nicht.

Wie ändere ich das denn ...

Wie gesagt: Im Idealfall einen zusätzlicher Normalisierungsschritt ausführen.

Alternativ: Zahlen kann man auch in der Programmierung als Zahlen behandeln, da ist keine Textverarbeitung notwendig:

Code [Auswählen] Erweitern

WHERE ID < 4400000 OR ID >= 4500000...

Ich bekomme die "Zahlen" als Text formatiert aus SAP via externer MS-SQL-DB (ODBC) als Verknüpfte Tabelle in meine Abfrage.