SQL Statement auseinandernehmen Like
Hi@All,
Ziel:
Beim erstellen eines Reports existiert ein Feld in der eine bestimmte OU ausgewählt werden kann.
Wird keine ausgewählt gilt die Auswahl auf alle, ansonsten auf die die ausgewählt wurde.
Problem:
Aktuell bekomme ich auch Rechner aus anderen OUs die garnicht in der Schnittmenge enthalten sein dürften.
Wenn ich das Statement richtig lese wird:
- wenn ALL ausgewählt wurde alle OUs genommen die in der Liste sind
- wenn direkt eine OU ausgewählt worden ist, wird diese genommen
Oder habe ich da was gänzlich missverstanden?
Gruß
Ziel:
Beim erstellen eines Reports existiert ein Feld in der eine bestimmte OU ausgewählt werden kann.
Wird keine ausgewählt gilt die Auswahl auf alle, ansonsten auf die die ausgewählt wurde.
Problem:
Aktuell bekomme ich auch Rechner aus anderen OUs die garnicht in der Schnittmenge enthalten sein dürften.
and [OU] like case when @Parameter_OU = 'ALL' then '%' Else ('%' + @Parameter_OU + '%') end
Wenn ich das Statement richtig lese wird:
- wenn ALL ausgewählt wurde alle OUs genommen die in der Liste sind
- wenn direkt eine OU ausgewählt worden ist, wird diese genommen
Oder habe ich da was gänzlich missverstanden?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 315129
Url: https://administrator.de/contentid/315129
Ausgedruckt am: 14.11.2024 um 17:11 Uhr
20 Kommentare
Neuester Kommentar
Hallo H41mSh1C0R,
das stimmt so nicht ganz, durch das like werden alle die geholt, die @parameter_ou enthalten.
D.h. wenn Du nach 'xyz' suchst, bekommst Du auch 'abxyz' und 'xyzz'.
Wenn nur exakt das gesuchte zurückkommen soll, dann müßte die Abfrage lauten:
Außerdem hast Du nicht die komplette Where-Bedingung hier reingeschrieben. Wenn da noch irgendwo ein "or" drin ist, dann kann dabei noch sonstwas dazugelesen werden.
Gruß, Mad Max
das stimmt so nicht ganz, durch das like werden alle die geholt, die @parameter_ou enthalten.
D.h. wenn Du nach 'xyz' suchst, bekommst Du auch 'abxyz' und 'xyzz'.
Wenn nur exakt das gesuchte zurückkommen soll, dann müßte die Abfrage lauten:
and [OU] = case when @Parameter_OU = 'ALL' then [OU] Else @Parameter_OU end
Außerdem hast Du nicht die komplette Where-Bedingung hier reingeschrieben. Wenn da noch irgendwo ein "or" drin ist, dann kann dabei noch sonstwas dazugelesen werden.
Gruß, Mad Max
Moin,
Von der Syntax her scheint der Schnippsel ja richtig zu sein.
Was kommt denn dabei rum, wenn du dein "CASE When" mit in den Select-Bereich einbindest?
Also
Und wie sieht dein Where-Statement in Gänze aus?
Nicht, dass dort irgendwo noch ein OR enthalten ist und dadurch zu deinem o.g. Statement eine alternative Auswahl (ungewollT) dargestellt wird.
Mit mehr Infos könnte man vermutlich etwas mehr Hilfe geben:
Gruß
em-pie
Von der Syntax her scheint der Schnippsel ja richtig zu sein.
Was kommt denn dabei rum, wenn du dein "CASE When" mit in den Select-Bereich einbindest?
Also
Select
-- prüfen, ob die CASE-Clause überhaupt greift
case
when @Parameter_OU = 'ALL' then 'ALLE'
Else 'Selektiert'
end as "TEST"
from
blablabla
Und wie sieht dein Where-Statement in Gänze aus?
Nicht, dass dort irgendwo noch ein OR enthalten ist und dadurch zu deinem o.g. Statement eine alternative Auswahl (ungewollT) dargestellt wird.
Mit mehr Infos könnte man vermutlich etwas mehr Hilfe geben:
- Welcher SQL-Server? (DB2, MSSQL 2005, Oracle, ...)
- Was ist in OU enthalten?
- Was ist in @parameter_ou enthalten
- Wie lang sind die Felder deklariert?
- Wie sieht dein gesamten (Where-)Statement aus?
Gruß
em-pie
naja Copy&Paste wäre ja auch machbar, zur Not via Textdatei.
Aber weiter im Text.
Der Hinweis von MadMax, dass du die %-Zeichen im Else-Zweig weglassen kannst, ist berechtigt.
Ich hatte gedacht, du wolltest dann, wenn die USer "Köln" auswählen auch OUs wie Neuköln oder Köln-Deutz haben
Ansonsten prüfe mal deine Tabelle, in der die Zurodnung OU = Parameter_OU enthalten ist
nicht, dass da irgendwie Werte doppelt vorkommen:
Und das = musst du mitnehmen, wäre, als wolltest du eine Abfrage über Merkmale von fahrzeugen starten:
Zeige alle Fahrzeuge mit Räder 3
Das System wüsste ja ncht, sollen es weniger als drei Räder sein oder exakt 3 Räder oder mehr als 3 Räder
Aber weiter im Text.
Der Hinweis von MadMax, dass du die %-Zeichen im Else-Zweig weglassen kannst, ist berechtigt.
Ich hatte gedacht, du wolltest dann, wenn die USer "Köln" auswählen auch OUs wie Neuköln oder Köln-Deutz haben
Ansonsten prüfe mal deine Tabelle, in der die Zurodnung OU = Parameter_OU enthalten ist
nicht, dass da irgendwie Werte doppelt vorkommen:
Parameter_OU | OU
Berlin | OU-Berlin
Köln | OU-Köln
Köln | OU-Dortmund
Hamburg | OU-Hamburg
Und das = musst du mitnehmen, wäre, als wolltest du eine Abfrage über Merkmale von fahrzeugen starten:
Zeige alle Fahrzeuge mit Räder 3
Das System wüsste ja ncht, sollen es weniger als drei Räder sein oder exakt 3 Räder oder mehr als 3 Räder
Hi
ich sehe das anders:
Diese case Statements kann man auflösen, je nachdem die Bedingung erfüllt ist oder nicht.
and [OU] like case when @parameter_ou = 'ALL' then '%' Else ('%' + @parameter_ou + '%') end
das ergibt im Falle dass @parameter_ou = 'ALL' ist:
and [OU] like '%'
Datensätze wo [OU] NULL ist werden dabei nicht ins Resultat übernommen!
falls der Wert in @parameter_ou <> 'ALL' ist (z.B. 'Köln') resultiert folgendes Kriterium:
and [OU] like '%Köln%'
falls der Wert in @parameter_ou = 'Köln, Frankfurt, Berlin' ist, resultiert folgendes Kriterium:
and [OU] like '%Köln, Frankfurt, Berlin%'
was wahrscheinlich nichts schlaues als Resultat gibt!
und falls der Wert in @parameter_ou leer ist (z.B. eine Zeichenkette mit der Länge Null)
and [OU] like '%%')
schliesslich falls @parameter_ou einen undefinierten Zustand hat (in SQL Server nennt man das NULL), dann gibts:
and [OU] LIKE NULL
und damit ist diese ganze Bedingung "ungültig"...
Das sind keine einfachen Bedingungen aber testweise einfach reproduzierbar.
ich sehe das anders:
Diese case Statements kann man auflösen, je nachdem die Bedingung erfüllt ist oder nicht.
and [OU] like case when @parameter_ou = 'ALL' then '%' Else ('%' + @parameter_ou + '%') end
das ergibt im Falle dass @parameter_ou = 'ALL' ist:
and [OU] like '%'
Datensätze wo [OU] NULL ist werden dabei nicht ins Resultat übernommen!
falls der Wert in @parameter_ou <> 'ALL' ist (z.B. 'Köln') resultiert folgendes Kriterium:
and [OU] like '%Köln%'
falls der Wert in @parameter_ou = 'Köln, Frankfurt, Berlin' ist, resultiert folgendes Kriterium:
and [OU] like '%Köln, Frankfurt, Berlin%'
was wahrscheinlich nichts schlaues als Resultat gibt!
und falls der Wert in @parameter_ou leer ist (z.B. eine Zeichenkette mit der Länge Null)
and [OU] like '%%')
schliesslich falls @parameter_ou einen undefinierten Zustand hat (in SQL Server nennt man das NULL), dann gibts:
and [OU] LIKE NULL
und damit ist diese ganze Bedingung "ungültig"...
Das sind keine einfachen Bedingungen aber testweise einfach reproduzierbar.
Hallo H41mSh1C0R,
der Einwand von ice.polar mit dem NULL-Wert ist grundsätzlich mal richtig, aber dürfte bei Dir nicht das Problem sein, weil das nämlich, wenn es auftreten kann, zu weniger Ergebnissen führt, als zu mehr. Ob [OU] oder @parameter_ou NULL werden können, mußt Du wissen und dann ggf. mit IsNull o.ä. abfangen.
Aber: wenn Du mit dem hier geschriebenen noch nicht Dein Problem gelöst hast, dann wirst Du wohl in den sauren Apfel beißen müssen und den Befehl abschreiben. Dann liegt nämlich das Problem wohl doch woanders und hellsehen kann hier glaube ich keiner. Hab ich zumindest noch nicht mitbekommen
Jedenfalls behaupte ich mal, wenn Du den Befehl gleich komplett abgeschrieben hättest, wäre Dein Problem wahrscheinlich schon gelöst. Und somit schneller gegangen als dieses ganze hin und her.
Gruß, Mad Max
der Einwand von ice.polar mit dem NULL-Wert ist grundsätzlich mal richtig, aber dürfte bei Dir nicht das Problem sein, weil das nämlich, wenn es auftreten kann, zu weniger Ergebnissen führt, als zu mehr. Ob [OU] oder @parameter_ou NULL werden können, mußt Du wissen und dann ggf. mit IsNull o.ä. abfangen.
Aber: wenn Du mit dem hier geschriebenen noch nicht Dein Problem gelöst hast, dann wirst Du wohl in den sauren Apfel beißen müssen und den Befehl abschreiben. Dann liegt nämlich das Problem wohl doch woanders und hellsehen kann hier glaube ich keiner. Hab ich zumindest noch nicht mitbekommen
Jedenfalls behaupte ich mal, wenn Du den Befehl gleich komplett abgeschrieben hättest, wäre Dein Problem wahrscheinlich schon gelöst. Und somit schneller gegangen als dieses ganze hin und her.
Gruß, Mad Max
Schaut auf den ersten Blick OK aus.
Wie willst du denn die Subbereiche abfragen?
Also wie sieht das Feld [OU] Inhaltlich aus?
stehen da die Werte wie "OU=Bereich 1, OU=Köln, OU=Regionen, OU=Company, DC=Company, DC=local" ?
Zitat von @H41mSh1C0R:
Hi Mad Max,
Der Select läuft auf einer DB fürs Patchen. In den OU's sind Standorte gegliedert und unter den OUs können noch Bereiche untergliedert sein.
Wenn nun einer OU Köln auswählt sollen halt alle Rechner einbezogen werden aus Bereich 1 und 2.
Momentan zeigt sich das allerdings so das auch Rechner aus 3 und 4 eingebunden werden.
In der Tabelle gibt es als Spalte OU. Das @parameter_ou ist ein Value in einem Label aus dem Report.
Hi Mad Max,
Der Select läuft auf einer DB fürs Patchen. In den OU's sind Standorte gegliedert und unter den OUs können noch Bereiche untergliedert sein.
Köln
Bereich 1
Bereich 2
Berlin
Bereich 3
Bereich 4
Wenn nun einer OU Köln auswählt sollen halt alle Rechner einbezogen werden aus Bereich 1 und 2.
Momentan zeigt sich das allerdings so das auch Rechner aus 3 und 4 eingebunden werden.
In der Tabelle gibt es als Spalte OU. Das @parameter_ou ist ein Value in einem Label aus dem Report.
Wie willst du denn die Subbereiche abfragen?
Also wie sieht das Feld [OU] Inhaltlich aus?
stehen da die Werte wie "OU=Bereich 1, OU=Köln, OU=Regionen, OU=Company, DC=Company, DC=local" ?
Hi
... und wählt einer "Köln, Berlin, Frankfurt" klappts auch nicht (andere Reihenfolge)...
Ich versteh's noch nicht ganz: hat es in der Tabelle v_PatchMan in der Spalte OU immer exakt eine OU (z.B. 'Berlin') oder stehen da schon alle möglichen (z.B. Köln, Berlin, Bern)? Ist die Reihenfolge da festgelegt oder könnte dann auch Köln, Bern, Berlin stehen?
Im Parameter @parameter_ou soll ja eben eine Auswahl an OU's zur Verarbeitung angegeben werden (z.B. Köln, Frankfurt, Berlin).
Dabei entsteht ein schöner Vergleich (n:n) zwischen v_PatchMan.ou und @parameter_ou.
... und wählt einer "Köln, Berlin, Frankfurt" klappts auch nicht (andere Reihenfolge)...
Ich versteh's noch nicht ganz: hat es in der Tabelle v_PatchMan in der Spalte OU immer exakt eine OU (z.B. 'Berlin') oder stehen da schon alle möglichen (z.B. Köln, Berlin, Bern)? Ist die Reihenfolge da festgelegt oder könnte dann auch Köln, Bern, Berlin stehen?
Im Parameter @parameter_ou soll ja eben eine Auswahl an OU's zur Verarbeitung angegeben werden (z.B. Köln, Frankfurt, Berlin).
Dabei entsteht ein schöner Vergleich (n:n) zwischen v_PatchMan.ou und @parameter_ou.
Hi,
Ich versteh' so langsam. In der Datenbank-Tabelle ist pro Datensatz eine einzige OU (inkl.Pfad, daher die Selektion mit Like).
In der Parameterliste (@Parameter_OU) kriegst Du eine Komma-separierte Liste: Eigentlich eine lange Zeichenkette.
Falls diese alle eine fixe Länge hätten, könnte man das direkt in SQL lösen. Fixe Länge bedeutet dass immer z.B. 20 Zeichen zwischen den Kommas sind ("Berlin ,Dortmund ,Ravensburg ").
Andernfalls ist eine procedurale Schlaufe ein Lösungsweg.
Ich versteh' so langsam. In der Datenbank-Tabelle ist pro Datensatz eine einzige OU (inkl.Pfad, daher die Selektion mit Like).
In der Parameterliste (@Parameter_OU) kriegst Du eine Komma-separierte Liste: Eigentlich eine lange Zeichenkette.
Falls diese alle eine fixe Länge hätten, könnte man das direkt in SQL lösen. Fixe Länge bedeutet dass immer z.B. 20 Zeichen zwischen den Kommas sind ("Berlin ,Dortmund ,Ravensburg ").
Andernfalls ist eine procedurale Schlaufe ein Lösungsweg.
Jetzt wird es auch für mich etwas transparenter
Habe gerade mal kurz gegoogelt und diesen Post (in einem anderen Forum) gefunden:
http://stackoverflow.com/questions/5493510/turning-a-comma-separated-st ...
Hier will der TO zwar das Problem lösen, dass er in einem Feld einer Bestandstabelle kommaseparierte Werte hat, aber das müsste sicherlich auch für dein @parameter_ou genauso funktionieren.
Schaue dir insbesondere mal den Post von Jayvee (ca. Anfang der 2. Hälfte) an.
Bilde vor deinem eigentlichen Statement eine temporäre Tabelle, welche alle relevanten Daten beinhaltet, und zwar nicht mehr kommasepariert und dann joinst du die mit deinem eigentlichen Statement.
Abschließend die Tabelle wieder leeren/ plattmachen.
Stichwort hier: Table Variable:
https://msdn.microsoft.com/de-de/library/ms175010.aspx
Habe das alles selbst aber nicht getestet noch nie verwenden müssen ;)
Habe gerade mal kurz gegoogelt und diesen Post (in einem anderen Forum) gefunden:
http://stackoverflow.com/questions/5493510/turning-a-comma-separated-st ...
Hier will der TO zwar das Problem lösen, dass er in einem Feld einer Bestandstabelle kommaseparierte Werte hat, aber das müsste sicherlich auch für dein @parameter_ou genauso funktionieren.
Schaue dir insbesondere mal den Post von Jayvee (ca. Anfang der 2. Hälfte) an.
Bilde vor deinem eigentlichen Statement eine temporäre Tabelle, welche alle relevanten Daten beinhaltet, und zwar nicht mehr kommasepariert und dann joinst du die mit deinem eigentlichen Statement.
Abschließend die Tabelle wieder leeren/ plattmachen.
Stichwort hier: Table Variable:
https://msdn.microsoft.com/de-de/library/ms175010.aspx
Habe das alles selbst aber nicht getestet noch nie verwenden müssen ;)