Telefonnummern in Adressdatenbank

[Otto Normalverbraucher]

Hallo,

ich habe eine Adressdatenbank in der Telefonnummern in allen möglichen und unmöglichen Formaten gespeichert sind.

Ich suche jetzt mit LIKE und "%15735499117%". Leider gibt es aber auch Telefonnummern mit "-" und Leerzeichen irgendwo mittendrin. Wie finde ich auch die?

[Rolf B]

Hallo Otto,

ich würde Dir empfehlen, eine Zusatzspalte hinzuzufügen, in der alles außer den Ziffern entfernt ist.

Das ist natürlich nicht so trivial. Wenn Du Nummern wie [phone] zusammen mit [phone] hast, musst Du genauer analysieren, ob die Sonderzeichen besondere Bedeutungen mitbringen. Und Du musst dann für Dich entscheiden, ob Du alle inländischen Nummern im internationalen Format speichern willst, oder ob Du ausländische Nummern nicht benötigst (ich plädiere für ersteres).

Ob das eine computed column sein kann, wie die Formel aussieht, ob Du die Spalte persistent definieren musst oder ob sie virtuell bleiben kann, und wie Du einen Index drauflegst damit sich die Sache auch lohnt, das hängt vom verwendeten Datenbankserver ab.

Wenn es keine computed column sein kann, solltest Du einen Trigger hinzufügen, der bei INSERT und UPDATE Operationen das Nummernsuchfeld für die betroffene Row neu aufbaut.

Welches DBMS verwendest Du?

Rolf

[Gunnar Bittersmann]

@@Rolf B

ich würde Dir empfehlen, eine Zusatzspalte hinzuzufügen, in der alles außer den Ziffern entfernt ist.

Warum Zusatzspalte? In der Datenbank sollten die Telefonnummern nur in der normalisierten Form stehen.

😷 LLAP

[dedlfix]

Tach!

ich würde Dir empfehlen, eine Zusatzspalte hinzuzufügen, in der alles außer den Ziffern entfernt ist.

Warum Zusatzspalte? In der Datenbank sollten die Telefonnummern nur in der normalisierten Form stehen.

Nein, nicht unbedingt, denn dann geht Information verloren, die du nicht durch simples Formatieren wiederhergestellt bekommst. Bei Firmen ist es üblich, die Durchwahlnummer von der Einwahlnummer mit Bindestrich abzutrennen. Wenn du den Bindestrich entfernst, kannst du ihn nicht wieder einfügen, wenn du nicht weißt, an welcher Stelle die Trennung zwischen beiden Nummernteilen ist. Auch können Leerzeichen zur besseren Erkennbarkeit der Teile eingefügt sein. Die könnte man zwar nach Regeln wieder einfügen, aber das ist nicht trivial. Dazu muss man die Besonderheiten der Länder kennen, besonders Ortsvorwahllängen und Sondernummern-Regelungen

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

ich würde Dir empfehlen, eine Zusatzspalte hinzuzufügen, in der alles außer den Ziffern entfernt ist.

Warum Zusatzspalte? In der Datenbank sollten die Telefonnummern nur in der normalisierten Form stehen.

Nein, nicht unbedingt, denn dann geht Information verloren, die du nicht durch simples Formatieren wiederhergestellt bekommst.

Ja. So wie ich das Zitat aus dem vorigen Posting stehenlassen hatte, ist auch nicht, wie ich „normalisieren“ meinte.

Ich hatte im Sinn (aber nicht in den Fingern): nicht alles außer den Ziffern entfernen, sondern die Telefonnummer in die Form [phone] (oder [phone]) bringen.

[phone] ist Rosis Faxnummer? 🤔

Die könnte man zwar nach Regeln wieder einfügen, aber das ist nicht trivial. Dazu muss man die Besonderheiten der Länder kennen, besonders Ortsvorwahllängen und Sondernummern-Regelungen

Ja. Aber mein iPhone kann das.

Hat dann auch den Vorteil, dass man alle Telefonnummern gleich (und richtig!) formatiert ausgibt; egal in welcher Schreibweise ein $Nutzer seine Nummer angegeben hat.

😷 LLAP

[dedlfix]

Tach!

Ich hatte im Sinn (aber nicht in den Fingern): nicht alles außer den Ziffern entfernen, sondern die Telefonnummer in die Form [phone] (oder [phone]) bringen.

Dabei bleibt das Problem mit der Suche aber bestehen.

Die könnte man zwar nach Regeln wieder einfügen, aber das ist nicht trivial. Dazu muss man die Besonderheiten der Länder kennen, besonders Ortsvorwahllängen und Sondernummern-Regelungen

Ja. Aber mein iPhone kann das.

Weil es dazu eine Library nutzt, in der all die Regeln versammelt sind. Meines Wissens müsste es eine frei verfügbare von Google geben, vielleicht auch andere. Damit kann man aber nur öffentlich bekannte Kriterien anwenden, wie die Ortsvorwahlen, und allgemeine Regeln (nach x Ziffern ein Leerzeichen einfügen). Die Trennung zwischen Einwahl und Durchwahl geht dabei aber verloren.

dedlfix.

[Raketenheinz]

Nein, nicht unbedingt, denn dann geht Information verloren, die du nicht durch simples Formatieren wiederhergestellt bekommst.

Das halte ich zumindest so lange für korrekt, wie die Herkunft der Daten und damit deren Eingabe-Format unbestimmt ist. Der Mehraufwand für das Speichern der (von wem auch immer manuell) getippten Nummer steht dann den Vorteil gegenüber, dass man diese auch manuell korrigieren kann.

Grund:

Niemand kann vorhersehen, was die Eintipper sich so ausdenken… Also kann das auch nicht mit irgendwelchen Garantien maschinell umgeformt werden. Menschliche Intelligenz ist, in der Gesamtbreite der Anwendungsmöglichkeiten betrachtet, der KI immer noch überlegen.

[Otto normalverbraucher]

Alle +, 49, () usw. habe ich schon aus dem Suchwort rausgefiltert. Mit % am Anfang und Ende werden nun alle gefunden bis auf die mit dem "-" und Leerzeichen irgendwo in der Nummer.

Ich verwende mysql.

[Rolf B]

Hallo Otto,

Alle +, 49, () usw. habe ich schon aus dem Suchwort rausgefiltert

Aus dem Suchwort? Also dem Input für die Suche? Ja, da musst Du natürlich auch filtern.

Du musst die Sonderzeichen aus dem Suchbegriff entfernen, aber aus den Telefonnummern in der DB auch! Deswegen habe ich Dir eine generierte Spalte vorgeschlagen, die eine normalisierte Version der Telefonnummer enthält.

Ich suche jetzt mit LIKE und "%15735499117%"

Fail - das würde auch die 0015735499117 ([phone]) finden. Das ist eine Windstream-Nummer für ein Mobiltelefon in Middletown, Montgomery County, Missouri (ehemals Prairie Township). Nomen est Omen - das ist tiefstes Redneck Land. 167 Einwohner, 1/3 unter der Armutsschwelle und 3 Kirchen 👀

Deswegen fragte ich nach dem Bedarf für eine Normalisierung auf nationaler oder internationaler Ebene. Aber normalisieren musst Du!

Wenn normalisiert ist, suchst Du einfach mit = statt mit LIKE.

Zum Normalisieren kann man eine Replace-Kette verwenden:

REPLACE(REPLACE(REPLACE(REPLACE(nummer,
                                ' ', ''),
                        '-', ''),
                '(', ''),
        ')', '')

das entfernt Space, Minus und Klammern. Ich habe die zugehörigen Parameter untereinandergestellt, damit man nicht den Überblick verliert.

Das Problem, ob Du eine nationale Nummer (015735499117) oder eine internationale Nummer (0015735499117 oder [phone]) hast, wird dadurch nicht behoben und es ist auch nicht so einfach behebbar. Man kann das mit einem CASE-Ausdruck angehen, aber das ist kompliziert.

CASE 
WHEN SUBSTR(nummer, 1, 2) = '00' THEN nummer
WHEN SUBSTR(nummer, 1, 1) = '+' THEN CONCAT('00', SUBSTR(nummer,2))
WHEN SUBSTR(nummer, 1, 1) = '0' THEN CONCAT('0049', SUBSTR(nummer,2)
ELSE '???'
END

Diese Case-Operation würde 00-Nummern unverändert lassen, aus +49... eine 0049-Nummer machen und nationale Nummern (0157354...) zu 0049157354 internationalisieren.

Und um DAS musst Du dann noch die REPLACE-Kette legen. Ziemlich umfänglich.

Besser ist es, für sowas eine Function als Stored Routine zu schreiben, das macht die Sache deutlich übersichtlicher.

In MYSQL ist beim Erzeugen eines generierten Suchfeldes noch zu beachten, dass nur InnoDB eine virtuell generierte Spalte indexieren kann. MyISAM kann nur auf stored generated columns einen Index legen. Guckst Du hier, Stichwort GENERATED.

Was Du keinesfalls tun darfst, ist eine Normalisierung in dem SELECT, der die Suche durchführt. Das führt dazu, dass kein Index genutzt werden kann und MySQL einen Tablescan machen muss. Tablescans sind der Tod jeder DB-Performance. Mit dem indexierten Suchfeld gelingt ein Index-Seek.

Rolf

[Der Martin]

Hallo Rolf,

Das Problem, ob Du eine nationale Nummer (015735499117) oder eine internationale Nummer (0015735499117 oder [phone]) hast, wird dadurch nicht behoben und es ist auch nicht so einfach behebbar. Man kann das mit einem CASE-Ausdruck angehen, aber das ist kompliziert.

CASE 
WHEN SUBSTR(nummer, 1, 2) = '00' THEN nummer
WHEN SUBSTR(nummer, 1, 1) = '+' THEN CONCAT('00', SUBSTR(nummer,2))
WHEN SUBSTR(nummer, 1, 1) = '0' THEN CONCAT('0049', SUBSTR(nummer,2)
ELSE '???'
END

so normalisierst du auf zwei führende Nullen und setzt außerdem voraus, dass eine Nummer, die mit nur einer Null beginnt, eine Nummer in Deutschland ist. Beides nicht gut.

Das Präfix für eine internationale Rufnummer ist in vielen Ländern, aber nicht überall die Doppel-Null. In den USA ist es meines Wissens die 010, in Österreich 09. Deswegen gilt nach internationalem Standard (irgendein ISO) das Pluszeichen als Ersatzzeichen für das im jeweiligen Land übliche Präfix.

Und im Code die 49 als Default-Ländervorwahl hartcodieren ist auch nicht schön. Wer weiß, ob derselbe Code nicht auch mal in Polen oder in Luxemburg laufen soll. Also besser als Config-Parameter.

Diese Case-Operation würde 00-Nummern unverändert lassen, aus +49... eine 0049-Nummer machen und nationale Nummern (0157354...) zu 0049157354 internationalisieren.

Eben. Und das ist nur richtig, solange diese Abfrage in DE stattfindet.

Live long and pros healthy,
 Martin

[MudGuard]

Hi,

Das Präfix für eine internationale Rufnummer ist in vielen Ländern, aber nicht überall die Doppel-Null. In den USA ist es meines Wissens die 010, in Österreich 09.

Bist Du sicher (bzgl. Österreich)? Ich meine, es ist auch dort die 00.

(Was nichts daran ändert, daß man für die Normalisierung doch eher das + verwenden sollte, da es ja Länder gibt, für die die Auslandsvorwahl nicht die Doppelnull ist)

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

Das Präfix für eine internationale Rufnummer ist in vielen Ländern, aber nicht überall die Doppel-Null. In den USA ist es meines Wissens die 010, in Österreich 09.

Bist Du sicher (bzgl. Österreich)? Ich meine, es ist auch dort die 00.

zumindest war das 1986 so, als unser Jahrgang im Ski-Schullandheim in Obertauern war. Da musste ich in der Telefonzelle im Ort die 0949 vorwählen, um nach Hause anzurufen.

Live long and pros healthy,
 Martin

[klawischnigg]

Hi there,

zumindest war das 1986 so, als unser Jahrgang im Ski-Schullandheim in Obertauern war. Da musste ich in der Telefonzelle im Ort die 0949 vorwählen, um nach Hause anzurufen.

Bist Du Dir da sicher? Von '09' hab ich noch nie etwas gehört. Ausserdem dürfte es da Probleme mit dem Routing geben. Mit '09' fangen in Österreich die Mehrwertnummern an. Was Du evt. verwechselst - früher begannen Kurzvorwahlen in Österreich mit '9'. '92' bspw. war die Kurzvorwahl für Wien (statt 0222), '993' für Graz (statt 0316) etc - kann sein, daß man damals mit '9' (ohne Null) + Ländervorwahl ins Ausland gekommen ist. Ich hör' davon anyway zum ersten Mal.

Abgesehen davon ist das ohnehin ein eher akademischer Disput, weil in Österreich im Gegensatz zu Deutschland praktisch niemand mehr einen Festnetzanschluss hat (größere Firmen und Ämter vielleicht ausgenommen) und somit ohnehin immer +49 etc. vorgewählt wird...😉

[Der Martin]

Hallo,

zumindest war das 1986 so, als unser Jahrgang im Ski-Schullandheim in Obertauern war. Da musste ich in der Telefonzelle im Ort die 0949 vorwählen, um nach Hause anzurufen.

Bist Du Dir da sicher? Von '09' hab ich noch nie etwas gehört. Ausserdem dürfte es da Probleme mit dem Routing geben. Mit '09' fangen in Österreich die Mehrwertnummern an.

war das in den 80ern auch schon so? Gab's die damals schon?

Was Du evt. verwechselst - früher begannen Kurzvorwahlen in Österreich mit '9'. '92' bspw. war die Kurzvorwahl für Wien (statt 0222), '993' für Graz (statt 0316) etc - kann sein, daß man damals mit '9' (ohne Null) + Ländervorwahl ins Ausland gekommen ist.

Das wäre schwierig, weil ja dann z.B. die 92 für Wien mit 9216 für Tunesien kollidieren würde, und die 993 für Graz mit der 993 für Afghanistan. Immerhin wurde zu der Zeit noch mechanisch-analog und Ziffer für Ziffer vermittelt.

Ich weiß jedenfalls, dass das mit der 09 als erste Ziffern auf der Anleitung an der Innenwand der Telefonzelle stand (Obertauern ist ja immerhin Touristen-Hochburg, außer vielleicht in den letzten 12 Monaten). Kann es sein, dass für Münzfernsprecher abweichende Regeln galten?

Abgesehen davon ist das ohnehin ein eher akademischer Disput, weil in Österreich im Gegensatz zu Deutschland praktisch niemand mehr einen Festnetzanschluss hat (größere Firmen und Ämter vielleicht ausgenommen) und somit ohnehin immer +49 etc. vorgewählt wird...😉

Mag sein. Aber jetzt interessiert es mich schon noch, was mir mein Langzeitgedächtnis da sagen will.

Live long and pros healthy,
 Martin

[klawischnigg]

Hi there,

Bist Du Dir da sicher? Von '09' hab ich noch nie etwas gehört. Ausserdem dürfte es da Probleme mit dem Routing geben. Mit '09' fangen in Österreich die Mehrwertnummern an.

war das in den 80ern auch schon so? Gab's die damals schon?

Keine Ahnung, eher nicht, aber siehe unten...😉

Was Du evt. verwechselst - früher begannen Kurzvorwahlen in Österreich mit '9'. '92' bspw. war die Kurzvorwahl für Wien (statt 0222), '993' für Graz (statt 0316) etc - kann sein, daß man damals mit '9' (ohne Null) + Ländervorwahl ins Ausland gekommen ist.

Das wäre schwierig, weil ja dann z.B. die 92 für Wien mit 9216 für Tunesien kollidieren würde, und die 993 für Graz mit der 993 für Afghanistan. Immerhin wurde zu der Zeit noch mechanisch-analog und Ziffer für Ziffer vermittelt.

Nein, 92 war die ganze Vorwahl, ohne führende Null, während Tunesion 09216 ist…

Ich weiß jedenfalls, dass das mit der 09 als erste Ziffern auf der Anleitung an der Innenwand der Telefonzelle stand (Obertauern ist ja immerhin Touristen-Hochburg, außer vielleicht in den letzten 12 Monaten). Kann es sein, dass für Münzfernsprecher abweichende Regeln galten?

Generell nicht, aber ich will nicht ausschliessen, daß die Trachtenpärchen irgendwie eigene Vorwahlregeln hatten, auch wenn's mir unwahrscheinlich erscheint. Eher, daß 9 die eigentliche Vorwahl war und Du mit Null eine Amtsleitung holen mußtest. In Tourismusgebieten will ich Münzfernsprecher in Privatbesitz nicht ausschliessen, da wäre eine "interne" Vorwahl möglich.

Allerdings hab ich von einer Länderkurzwahl nichts gefunden (ich hab jetzt einmal da nachgeschaut, deswegen kommt mir meine Theorie jetzt irgendwie nicht mehr glaubhaft vor)

Mag sein. Aber jetzt interessiert es mich schon noch, was mir mein Langzeitgedächtnis da sagen will.

Vermutlich, daß Du im Schulschiurlaub in der Telefonzelle eine Sexhotline angerufen hast, das hast Du dann verdrängt und einen Anruf bei Mutti draus gemacht...😉

[Rolf B]

Hallo Martin,

da die Frage von Otto Normalverbraucher kommt und nicht von Franz Normalkonsument oder Urs Normalkäufer, habe ich auf den deutschen Teil vom DACH getippt.

so normalisierst du auf zwei führende Nullen und setzt außerdem voraus, dass eine Nummer, die mit nur einer Null beginnt, eine Nummer in Deutschland ist. Beides nicht gut.

Für einen in Deutschland befindlichen Anwender ist es perfekt. Wer nicht in Deutschland sitzt, braucht andere Regeln, ja. Wer in Deutschland in einem Unternehmen sitzt, braucht noch andere Regeln (im Büro normalisiere ich für unser Callcenter auf 00049).

Alles weitere schätze ich für den OP als irrelevant ein. Wenn das ein Irrtum ist, kann er sich melden und wir diskutieren weiter drüber. Ich hab's eh schon komplex genug gemacht, das muss erstmal verstanden werden.

Wikipedia sagt übrigens, die USA hätten 011 als Internationale Verkehrsausscheidungsziffer.

Rolf

[Raketenheinz]

Ich habe da zufällig was “fertiges” - das kannst Du an Deine Bedürfnisse anpassen.

An den Inserts erkennst Du (grob), welche Telefonnummern es verarbeitet.

• Die Tabelle wird angelegt und mit den Testdaten gefüttert.

Dann werden:

1. Die Spalte t gelesen und in dem String
2. führende ++ und 00 zu + - sodann
3. die Angabe (0) entfernt - sodann
4. führende Nullen durch 49 ersetzt
5. alles, was keine Ziffer ist entfernt
6. 00 davor notiert.
7. Der neue String wird in der Spalte t_n eingefügt.

Zuletzt wird die Tabelle ausgegeben.

USE `test`;
DROP TABLE IF EXISTS `ptest`;
CREATE table `ptest`(  `t` TEXT(30) ,  `t_n` TEXT(30) );

INSERT INTO `ptest` (`t`) VALUES('099 123456789');
INSERT INTO `ptest` (`t`) VALUES('099 1234567 89');
INSERT INTO `ptest` (`t`) VALUES('0049 99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('[phone]');
INSERT INTO `ptest` (`t`) VALUES('++49 99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('0049 (0)99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('[phone]');
INSERT INTO `ptest` (`t`) VALUES('++49 (0)99 1234567-89');

UPDATE `ptest` SET `t_n` = 
	CONCAT ( 
		'00',
		REGEXP_REPLACE (
			REGEXP_REPLACE (
				REPLACE (
					REGEXP_REPLACE( 
						t,
						'^\\+\\+|^00',
						'+'
					),
					'(0)',
					''
				),
				'^0',
				'+49'
			),
			'[^0-9]',
			''
		)
	)
;
SELECT `t`, `t_n` FROM `ptest`;

Weitere Anpassungen an Deine Bedürfnisse sind wahrscheinlich notwendig, aber eigentlich "nur noch Arbeit". So sollte z.B. ein Index für die Suche geschaffen werden.

[Raketenheinz]

Ich habe da zufällig was “fertiges” - das kannst Du an Deine Bedürfnisse anpassen.

Ach so. Das ist mit MariaDB 10.5.10 getestet. Leider ist es so, dass sich die Syntax von REGEXP_REPLACE zwischen aktuellen und älteren Versionen von MySQL/MariaDB unterscheidet.

Du hast aber nichts dazu angegeben.

[Rolf B]

Hallo Raketenheinz,

An REGEX_REPLACE hatte ich auch gedacht. Ich weiß aber nicht, welches die gängigen Versionen von MySQL/MariaDB sind und diese Funktion ist erst in MySQL 8. Bei MariaDB weiß ich es nicht.

In anderen DBMS müsste man erstmal gucken was da angeboten wird.

Rolf

[Raketenheinz]

Ich habe das für MariaDB mal nachgeschaut und folgendes gefunden:

REGEXP_REPLACE was introduced in MariaDB 10.0.5.

https://mariadb.com/kb/en/regexp_replace/

MariaDB 10.0.5 Release Notes

Status: Beta | Release Date: 7 Nov 2013

https://mariadb.com/kb/en/mariadb-1005-release-notes/

In der nächsten Stable war es dann drin.

[dedlfix]

Tach!

ich habe eine Adressdatenbank in der Telefonnummern in allen möglichen und unmöglichen Formaten gespeichert sind. Wie finde ich auch die?

Eine einigermaßen schlechte Idee ist, einen RegExp-Ausdruck zu erstellen, der zwischen den Ziffern Sonderzeichen erlaubt, und damit zu suchen. Aber dann muss jeder Datensatz einzeln geprüft werden, was einen Full Table Scan erfordert. Besser ist die von Rolf B bereits propagierte Vorgehensweise mit einer extra Spalte für die Suche. Das ist auch eine übliche Vorgehensweise, wenn von Daten die originale Schreibweise erhalten bleiben soll, sich aber für die Suche eine andere Schreibweise besser eignet.

dedlfix.

[Raketenheinz]

Ich habe die bereits vorgestellte Lösung für MySQL >=8 und MariaDB >= 10.0.5 so vervollständigt, dass eine Funktion erstellt wird, welche sodann für Updates, Inserts und Where-Klauseln benutzt werden kann:

USE `test`;
DROP TABLE IF EXISTS `ptest`;
CREATE table `ptest`(  `t` TEXT(30) ,  `t_n` TEXT(30) );

INSERT INTO `ptest` (`t`) VALUES('099 123456789');
INSERT INTO `ptest` (`t`) VALUES('099 1234567 89');
INSERT INTO `ptest` (`t`) VALUES('0049 99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('[phone]');
INSERT INTO `ptest` (`t`) VALUES('++49 99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('0049 (0)99 1234567-89');
INSERT INTO `ptest` (`t`) VALUES('[phone]');
INSERT INTO `ptest` (`t`) VALUES('++49 (0)99 1234567-89');

DROP FUNCTION IF EXISTS t_clear;
DELIMITER $$
CREATE FUNCTION t_clear (s TEXT(30) ) RETURNS text(30)
BEGIN
	SET s = CONCAT ( 
		'00',
		REGEXP_REPLACE (
			REGEXP_REPLACE (
				REPLACE (
					REGEXP_REPLACE( 
						s,
						'^\\+\\+|^00',
						'+'
					),
					'(0)',
					''
				),
				'^0',
				'49'
			),
			'[^0-9]',
			''
		)
	);
	RETURN s;
END$$
DELIMITER ;

UPDATE `ptest` SET `t_n` = t_clear(`t`);

INSERT INTO `ptest` VALUES ( '0561 123456789', t_clear('0561 123456789') );

SELECT '- ALLE: -----------------------------------------------' as '';
SELECT `t`, `t_n` FROM `ptest`;
SELECT '- Mit 049561 beginnend: -------------------------------' as '';
SELECT `t`, `t_n` FROM `ptest` WHERE `t_n` LIKE '0049561%';
SELECT '- Mit 0561 beginnend: ----------------------------------' as '';
SELECT `t`, `t_n` FROM `ptest` WHERE `t_n` LIKE CONCAT( t_clear('0561'), '%' ) ;
SELECT '-------------------------------------------------------' as '';

Tabelle und Funktion müssen natürlich nur einmal erstellt und das Update nur einmal durchgeführt werden. Bereits existierende Abfragen müssen dann natürlich auch angepasst werden…

[Raketenheinz]

Oh je. Das SQL-Skript hatte ich gefunden, als ich eigentlich das hier suchte. Google war soeben so freundlich, meinem Gedächtnis nachzuhelfen…