Nun ja, er sprach von 64 Kombinationen und nicht von 64 Variablen.
Von NULL-Werten war nicht die Rede und es zeigt, dass du meine Variante nicht verstanden hast, denn ich wollte keine NULL-Werte abfragen.
Es wurde auch interpretiert, dass die Variablen Inhalte haben könnten, die aber nicht relevant wären, was man eben mit NULLInd lösen kann, da dann der Inhalt nicht zählt.
DISTINCT löst auch nur das Gleichheitsproblem, allerdings nicht Vergleiche mit Like, <, >, usw.

Was hast du also gegen (:P = ('' | 0) or Feld = :P), wobei das = eben auch mit allen anderen Vergleichen funktioniert. Ich habe sogar schon (:P = '' or Feld in Split(:P, ',')) ausgeführt um Mehrfachauswahlen zu lösen. P enthält dann eine kommaseparierte Liste von Werten.
Phänomenal das Ganze. Und jetzt schreib nicht wieder, dass es Split so nicht gibt. Das weiß ich ja.
Und wenn du NULL haben willst, füge doch einfach einen "or Feld is Null" hinzu.
Und bevor du fragst: ('' | 0) soll heißen typgerecht entweder '' oder 0.

Und was solls. Es ist doch einfacher einen statischen SQL zu bauen, der alle Variablen enthält und die Prüfung ob relevant ganz einfach ist als einen dynamischen SQL zu bauen, der auch auch die verschiedenen Varianten abfragen muss um ihn zu bauen und außerdem nicht mit Parametern sondern mit Stringkonstanten arbeiten muss, %edit, oder das O'Hara-Problemen lässt grüßen.
Auch CCSID-Probleme mit Unicode (1200) oder SBCS (1141) kommen noch dazu, was Parameter eben erleichtern. Du müsstest den prepared String nämlich besser als Unicode (1200) aufbauen.

Ich baue meine Abfragen schon seit Jahrzehnten genau so auf und erstaunlicherweise funktionieren sie auch noch schnell.