Hallo Ayomler,

arbeitet einer von euch mit dem MS SQL Server Management Studio und kann mir sagen ob ich hier in den Where-Klauseln RegExp's einsetzen kann?
Und wenn ja wo ich hinweise zur entsprechenden Syntax finde?
G..gle hilft mir leider nicht weiter und die Hilfe des Studios finde ich ehrlich gesagt ziemlich unbrauchbar...

Danke&Gruß,
Tom

Ich habe noch nie davon gehört, dass man Reqular Expressions direkt in SQL nutzen kann. Da ändert auch das Querytool nichts dran (auch wenn das Management Studio fast schon mehr als ein reines Querytool ist).

Verwendet hab ich's noch nicht, aber wenn selbst mySQL das kann, dann wird T-SQL wohl nicht nachhinken ... einfach mal auf jAuer warten, der wird's wissen *gg*

Die Suche nach den Stichwörtern "T-SQL Regexp" ergibt übrigens einige Treffer ...

Das ist dann doch interessant. Kann MySQL Regex direkt im Querystring?
So wie ich jetzt kurz die Beispiele bei Google durchgesehen habe, klappt das bei T-SQL nur mit Stored Procedures und nicht nativ in dem Sinne.

@TSc: Solltest du mit ASP.NET arbeiten, schau dir Linq to SQL an und all deine Probleme (betreffend Abfragen) sind gegessen!

Danke für den Hinweis!

bzgl. mySQL und RegExp:
http://dev.mysql.com/doc/refman/5.0/en/regexp.html

Eventuell hilft dir dies... http://msdn2.microsoft.com/de-de/magazine/cc163473.aspx

Mir sind zwei prinzipielle Lösungen bekannt.

(1) Über OleDb, die per 'T-Sql RegEx' auffindbaren Artikel liefern Beispiele.
(2) Per CLR-Prozedur auf dem Sql2005, das ist der Link von @Webi.

Problem bei ersterem: Man muß den Zugriff auf die OLE-Prozeduren gestatten, je nach Situation kann das zu Sicherheitsproblemen führen. Man kann ja dann auf so ziemlich alles zugreifen.

Problem bei zweiterem: Die Integration von .NET in den Sql2005 ist zwar eine wunderbare Idee, hat aber im praktischen Betrieb immer wieder zu ekeligen Problemen geführt. Wenn man das Assembly ändert, dann reicht es bei einer Webanwendung, das einfach reinzukopieren. Die Laufzeitumgebung bemerkt die Änderung, kompiliert das neu, läßt die noch laufenden Threads auf der alten DLL zu Ende laufen und startet die neuen Anfragen über den neuen Code - wunderbar.

Der Sql2005 lädt das irgendwie so direkt, daß das nicht geht. Man muß alle auf dieser Assembly basierenden erweiterten Prozeduren löschen, das Assembly löschen, neu installieren, die Prozeduren (einschließlich Berechtigung) neu erstellen. Das alles ginge ja noch. Aber ich wollte das u.a. zum Mailversand nutzen, damit wurden diverse andere Assemblies nachgeladen, die durchweg als UNSAFE reinkommen. Und wenn man dann hinreichend häufig das Assembly aktualisiert hat - läßt sich das plötzlich nicht mehr laden. Technisch hilft dann nur ein Neustart des SqlServer-Dienstes. Bei laufendem Betrieb nicht denkbar, glücklicherweise bin ich über das Problem mal abends gestolpert, als es einigermaßen ruhig war.

Resultat: Bei server-daten läuft inzwischen ein eigener Dienst, der Remote-Objekte zur Verfügung stellt. Der Sql2005 lädt nur noch eine winzige abstrakte Klasse mit Schnittstellendefinitionen, anstatt daß er tonnenweise UNSAFE Assemblies laden muß - und ruft die Funktionen remote auf. Für meine Zwecke reicht das - aber das ist natürlich sehr viel langsamer als ein In-Process-Aufruf.

Und es ist eine 'nicht ganz unaufwendige' Architektur, auch da will ich ja das Assembly aktualisieren, ohne den Dienst neu starten zu müssen. Geht - ist aber nicht ganz simpel, läuft analog in zwei Varianten auf dem Webserver.