6
MSSQL regular expressions
Nabend
Ich habe ein bischen gebastelt und bin auf etwas für mich merkwürdiges gestoßen. Wenn ich eine Werteliste mit LIKE suche, funktioniert das. Auch funktionieren Wertebereiche aber beides kombinieren ist irgendwie sonderbar, vor allem wenn ich versuche Leerzeichen zu berücksichtigen.
funktioniert:
@Data LIKE '[AA,BB,CC]%'
@Data LIKE '[A-C][A-C]%'
@Data LIKE '[AA,BB,CC][A-C]%'
funktioniert nicht:
@Data LIKE '[AA,BB,CC][ ][A-C]%'
@Data LIKE '[AA,BB,CC] [A-C]%'
@Data LIKE '[AA ,BB ,CC ]%'
@Data LIKE '[AA,BB,CC]' + CHAR(32) + '%'
hier kommen sogar false positives zustande:
@Data = 'AA1'
@Data LIKE '[AA,BB,CC][A-C]%'
Sonderzeichen wie Punkt, Komma, etc. funktionieren auch in Wertelisten ganz gut. Aber mir ist irgendwie überhaupt nicht klar wann was funktioniert. Auch _ für ein belibiges Zeichen funktioniert an der Stelle des Leerzeichens nicht.
Ich habe ein bischen gebastelt und bin auf etwas für mich merkwürdiges gestoßen. Wenn ich eine Werteliste mit LIKE suche, funktioniert das. Auch funktionieren Wertebereiche aber beides kombinieren ist irgendwie sonderbar, vor allem wenn ich versuche Leerzeichen zu berücksichtigen.
funktioniert:
@Data LIKE '[AA,BB,CC]%'
@Data LIKE '[A-C][A-C]%'
@Data LIKE '[AA,BB,CC][A-C]%'
funktioniert nicht:
@Data LIKE '[AA,BB,CC][ ][A-C]%'
@Data LIKE '[AA,BB,CC] [A-C]%'
@Data LIKE '[AA ,BB ,CC ]%'
@Data LIKE '[AA,BB,CC]' + CHAR(32) + '%'
hier kommen sogar false positives zustande:
@Data = 'AA1'
@Data LIKE '[AA,BB,CC][A-C]%'
Sonderzeichen wie Punkt, Komma, etc. funktionieren auch in Wertelisten ganz gut. Aber mir ist irgendwie überhaupt nicht klar wann was funktioniert. Auch _ für ein belibiges Zeichen funktioniert an der Stelle des Leerzeichens nicht.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 435059
Url: https://administrator.de/forum/mssql-regular-expressions-435059.html
Ausgedruckt am: 28.03.2025 um 10:03 Uhr
6 Kommentare
Neuester Kommentar
Gibt eine Million Treffer mit "masking regular expressoins in sql". Blank ist übrigens \s
und hier steht der Rest:
Stackoverflow - Erklärung für Regex in Where klauseln
und hier steht der Rest:
Stackoverflow - Erklärung für Regex in Where klauseln
Zunächst mal Danke für den Versuch aber Google habe ich natürlich auch bemüht. Dein Treffer und \s etc. sind für MySQL, ich habe MSSQL 2014.
https://docs.microsoft.com/de-de/sql/t-sql/language-elements/like-transa ...
Meine Probleme haben eine andere Ursache. Scheinbar unterstützt LIKE die Angabe einer Werteliste mit , getrennt in eckigen Klammern nicht. Das scheint nur mit patindex() zu gehen.
PS: Okay unter gewissen umständen läuft es mit der Werteliste scheinbar, alles sehr seltsam.
https://docs.microsoft.com/de-de/sql/t-sql/language-elements/like-transa ...
Meine Probleme haben eine andere Ursache. Scheinbar unterstützt LIKE die Angabe einer Werteliste mit , getrennt in eckigen Klammern nicht. Das scheint nur mit patindex() zu gehen.
PS: Okay unter gewissen umständen läuft es mit der Werteliste scheinbar, alles sehr seltsam.
Baut man sich halt eine Regex Custom User Skalar Function für MSSQL 
using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
using System.Text.RegularExpressions;
public partial class UserDefinedFunctions
{
[Microsoft.SqlServer.Server.SqlFunction]
public static SqlBoolean CheckRegex(string strPattern, string strValue) {
Regex r = new Regex(strPattern);
return r.IsMatch(strValue);
}
}
Hallo ukulele,
das funktioniert schon alles richtig, auch Dein "false positive".
Was in eckige Klammern eingeschlossen ist, ist der mögliche Wertebereich für genau ein Zeichen. Da darfst Du auch Listen und Bereiche kombinieren. Steht übrigens sehr schön in der Hilfe zu dem Befehl like
Wenn Du ein bestimmtes Zeichen an einer Stelle suchst, dann brauchst Du auch keine eckigen Klammer, es sei denn, es ist ein Joker wie z.B. % oder _.
Dein Beispiel für das falsche Ergebnis erklärt sich also so:
@Data = 'AA1'
@Data LIKE '[AA,BB,CC][A-C]%'
Erstes Zeichen muß bei den Zeichen in der ersten eckigen Klammer sein, also A, B, C oder das Komma. Daß die Zeichen doppelt aufgeführt sind, stört offensichtlich nicht. Das erste Zeichen erfüllt jedenfalls die Bedingung, A ist in der Auflistung enthalten.
Das zweite Zeichen muß im Bereich A-C sein. das ist auch erfüllt.
Der Rest ist dann beliebig. Bedingung ist also erfüllt.
Wenn Du also am Anfang AA oder BB oder CC erwartest, dann müßtest Du das anders machen, nämlich:
@Data like 'AA%' or @Data like 'BB%' or @Data like 'CC%'
oder
left (@Data, 2) in ('AA', 'BB', 'CC')
Gruß, Mad Max
das funktioniert schon alles richtig, auch Dein "false positive".
Was in eckige Klammern eingeschlossen ist, ist der mögliche Wertebereich für genau ein Zeichen. Da darfst Du auch Listen und Bereiche kombinieren. Steht übrigens sehr schön in der Hilfe zu dem Befehl like
Wenn Du ein bestimmtes Zeichen an einer Stelle suchst, dann brauchst Du auch keine eckigen Klammer, es sei denn, es ist ein Joker wie z.B. % oder _.
Dein Beispiel für das falsche Ergebnis erklärt sich also so:
@Data = 'AA1'
@Data LIKE '[AA,BB,CC][A-C]%'
Erstes Zeichen muß bei den Zeichen in der ersten eckigen Klammer sein, also A, B, C oder das Komma. Daß die Zeichen doppelt aufgeführt sind, stört offensichtlich nicht. Das erste Zeichen erfüllt jedenfalls die Bedingung, A ist in der Auflistung enthalten.
Das zweite Zeichen muß im Bereich A-C sein. das ist auch erfüllt.
Der Rest ist dann beliebig. Bedingung ist also erfüllt.
Wenn Du also am Anfang AA oder BB oder CC erwartest, dann müßtest Du das anders machen, nämlich:
@Data like 'AA%' or @Data like 'BB%' or @Data like 'CC%'
oder
left (@Data, 2) in ('AA', 'BB', 'CC')
Gruß, Mad Max
Ja danke nochmal für die Klarstellung. Nachdem ich nochmal alles nach "Wertelisten" mit mehr als einem Buchstaben abgesucht habe musste ich das auch so schlussfolgern. Offensichtlich habe ich hier früher theoretisch Fehler gemacht die aber nicht relevant waren, eben weil das , auch ein Wert war der gesucht wurde.
Auch wichtig zu wissen das patindex() und LIKE die selbe Syntax akzeptieren.
Leider suche ich im Text stellen die mit 2, 3 oder 4 Buchstaben anfangen, dann wahlweise einen Leerschritt haben oder eben auch nicht und auf die dann eine Zahl mit bis zu 7 Stellen folgt. Da es keine Möglichkeit gibt zwischen z.B. Leerschritt oder kein Zeichen in LIKE zu unterscheiden nur immer ziwschen Leerschritt oder einem anderen Zeichen (über die Werteliste) sind die möglichen Kombinationen zahlreich.
Ich werde versuchen es mit SQL Mitteln zu lösen, vielleicht baue ich mir hier eine Funktion. left() ist schon ein sinniger Ansatz, vielleicht in Kombination mit replace() um das Leerzeichen, falls vorhanden zu killen.
Auch wichtig zu wissen das patindex() und LIKE die selbe Syntax akzeptieren.
Leider suche ich im Text stellen die mit 2, 3 oder 4 Buchstaben anfangen, dann wahlweise einen Leerschritt haben oder eben auch nicht und auf die dann eine Zahl mit bis zu 7 Stellen folgt. Da es keine Möglichkeit gibt zwischen z.B. Leerschritt oder kein Zeichen in LIKE zu unterscheiden nur immer ziwschen Leerschritt oder einem anderen Zeichen (über die Werteliste) sind die möglichen Kombinationen zahlreich.
Ich werde versuchen es mit SQL Mitteln zu lösen, vielleicht baue ich mir hier eine Funktion. left() ist schon ein sinniger Ansatz, vielleicht in Kombination mit replace() um das Leerzeichen, falls vorhanden zu killen.
Hallo ukulele,
für patindex hatte ich bis jetzt noch nicht wirklich Verwendung, aber ja, in der Hilfe steht, daß es wie like funktioniert.
Aber dann ist es doch relativ einfach, solche Texte aufzuteilen. Wenn es wirklich wie like funktioniert, findet man mit "select patinidex ('%[0-9]%', @Data)" die erste Ziffer. Ob davor ein Leerzeichen oder zwei bis vier Buchstaben stehen, kann man dann ja einfach ermitteln.
Gruß, Mad Max
für patindex hatte ich bis jetzt noch nicht wirklich Verwendung, aber ja, in der Hilfe steht, daß es wie like funktioniert.
Aber dann ist es doch relativ einfach, solche Texte aufzuteilen. Wenn es wirklich wie like funktioniert, findet man mit "select patinidex ('%[0-9]%', @Data)" die erste Ziffer. Ob davor ein Leerzeichen oder zwei bis vier Buchstaben stehen, kann man dann ja einfach ermitteln.
Gruß, Mad Max
