Hi,

am besten ich sage in Delphi, was ich will.



Es sollen also nur Zahlen zurückgeliefert werden, egal was in inp übergeben wird. Zweck ist es, Doubletten bei Telefonnummern zu vermeiden. Z.B. 030/12345 und 030-12345, bzw. diese zu erkennen.

Hallo!



LG
Stefan

So simplen Fehler hätte ich schon bemerkt. Das habe ich aber nur für die Frage so getippt. Aber war klar. Titel muss in der Frage wiederholt werden.

per SQL unzulässige Zeichen entfernen

Das was ich da mit Delphi mache, das muss in der Datenbank passieren. Entweder als SP oder direkt mit dem DataSet. Letzteres würde wohl zu unübersichtlich. Außerdem brauche ich Rückgabewert.

tja, hansa, da bin ich nicht deiner meinung. denke es wird vorzugsweise das gespeichert was in die DB gehört. als, hier die tel. nr. ohne optischen schnickschnack .. und erst bei der darstellung wird dann die nummer richtig formatiert. dann kann man auch vernünftig suchen...

Genzgaenger, man muss manchmal eben weiterdenken. Und für die DAUs gleich mit.

Zitat:

..Doubletten bei Telefonnummern zu vermeiden. Z.B. 030/12345 und 030-12345, bzw. diese zu erkennen.

Warum soll ich einen User in ein Korsett zwängen und ihn eventuell ärgern, obwohl unnötig ? Der soll die Nummern ruhig so eingeben können, wie er gerade lustig ist. Zumindest bis zu einem gewissen Punkt. Durchwahl könnte man z.B. so realisieren : 030/12345-100 Jetzt folgender Fall : Urlaubsvertretung verwechselt das und legt folgende Nr. ein : 030-12345/100 Wird das so gespeichert, dann merkt die DB nichts davon und tut das auch. Anderenfalls wird die Tipse wohl sagen : "das geht nicht" und nervt dann mich. Gebe ich Masken vor und speichere nur 03012345100, dann ist es wohl ein erheblicher Aufwand diese Tel.Nr. in gewohnter Weise als 030/12345-100 anzuzeigen. Mit Format, Maskedit usw.

Ist die Nummer einmalig als 030/12345-100 in der DB, dann braucht man nur die Sonderzeichen wegzumachen und diese davon bereinigte Zahl mit der genauso zu behandelnden eingegebenen Zahl zu vergleichen und fertig. Die Schreibeweise wäre dann völlig egal. Doppeleingaben gingen dann nicht mehr.

P.S.: viele andere hätten einfach gesagt : "aus versch. Gründen muss das so sein"

tja, trotzdem würd ich die zahl auch normiert in die DB speichern. dann kann man z.b. die tel. nummer nach benutzerwünschen problemlos aufbereiten und ausdrucken.. und jeder ist begeistert... ausser der programmierer, weil er mehr arbeit hat

Zitat:

hansa030/12345-100

weisst ja, dass man dafür normal 4 felder in der DB nimmt [ländervorwahl, vorwahl, telefonnummer, durchwahl (auch wenn es 'ne durchwahl in verschiedenen ländern gar nicht gibt )] und dann ist ja das formatieren recht einfach...

Hallo,

wenn du mit einem langsameren Query leben kannst, dann kannst du folgendes machen. Nutze deinen Delphi Code um alle Sonderzeichen aus der zu suchenden Telefonnummer zu entfernen und setze dann an jeder 2ten Stelle ein % ein. Den so generierten Wert verwendest du dann in einer LIKE abfrage.

Dein Query würde also etwa so aussehen:



Die Ergebnisse kannst du notfalls ja noch einmal im Delphi gegenprüfen da ich nicht sicher bin ob das nicht auch Fehltreffer liefern könnte. Sicher ist aber wenn kein Ergebnis zurück kommt, ist deine Nummer nicht in der Tabelle.

Gruß
Klabautermann

PS: Performanter ist es aber sicherlich, wenn du die Telefonnummern noch ein zweites mal ohne Sonderzeichen ablegst.

@hansa: fällt mir grad auf, deine funktion hat 'n kleinen fehler. was machst du mit den nummern die wie folgt aufgebaut sind +41101001 oder ++44595999995? da darfst nicht einfach bei der 4 anfangen sondenr musst stattdessen noch schöne nullen setzen .

wie gesagt, ich würd das ganze unkonvertiert in der db speichern. zum konvertieren würd ich mir vielleicht 'ne kleine function oder 'n object schreiben welches die formatierung in beide richtungen übernimmt... alternativ kannst auch 'n record verwenden und mit den class operators (+, -, =, :=, ...) arbeiten, dann läuft das vollkommen transparent in deinem code

Grenzgaenger hat folgendes geschrieben:

.. was machst du mit den nummern die wie folgt aufgebaut sind +41101001 oder ++44595999995? da darfst nicht einfach bei der 4 anfangen sondenr musst stattdessen noch schöne nullen setzen .

Gegenfrage : was mache ich mit den DB-Feldern, die so aussehen :

Land : ++49
Vorwahl : 030
Tel.Nr. : 12345
Durchwahl 678

Genau : schön Nullen setzen oder entfernen. Vor allem die führende bei 030 müsste weg. Bei Zentrale ist dann eine 0 hinten einzufügen (manchmal auch 00) usw.

Nun gut, bevor die Theorie zu sehr ausufert muss ich wohl noch weiter ausholen. Ist halt Denksportaufgabe. Ich erhalte z.B. folgende Telefonnummern :

030123450
0301234512345
00352654321

Da ist kein +/- usw. enthalten. Momentan sehe ich den Anrufer mit der entsprechenden Nummer. Also nur die Nummer !! Vorerst in Memo (Wird von ISDN-Capi geliefert). Ziel ist es, den Anrufer genauer zu identifizieren, sofern er in DB angelegt ist. Also Name etc.

Anhand dieser gelieferten Nr. muss der Anrufer aus der DB gefischt werden. Habe mich nun selber angelegt ohne Sonderzeichen in der Nummer. Wird bei Anruf von mir selber auch schön angezeigt. Aber nur, weil so was wie 030123451234521434 in der DB steht.

Hi hansa,

wir haben ein ähnliches Problem: Adressenlisten. Hier haben wir eine einfache Unschärfensuche entwickelt, mit der wir gute Ergebnisse erzielen: Sinn ist es, die Schreibweise zu vereinfachen, um Tippfehler zu ignorieren. Wir verwenden, weil es sich um Adressen handelt, eine phonetische Transformation, Du brauchst ja nur die Sonderzeichen zu eliminieren und eine Heuristik, die z.B. Vorwahl von der Telefonnummer trennt.

Die Stored Procedure kannst du sicherlich in FB selbst programmieren (Du bist ja mit FB verheiratet ). Wir haben zu MSSQL ein ähnliches Verhältnis (mit allen Höhen und Tiefen) und haben bemerkt, das SQL hier ziemlich langsam ist, also eine Mittelschicht ca. 10-20% Performancegewinn bringt. SQL ist einfach nicht schnell genug, um Stringoperationen performant auszuführen

Ich würde:
a) Landes- und Ortsvorwahl sowie Telnr getrennt eingeben lassen
ODER
b) Landes und Ortsvorwahl von der Telnr. trennen und anhand einer Liste die Plausibilität testen. Die deutschen und internationalen Vorwahlen gibts überall im Netz.

Wir haben mit a) schon genug Probleme ('123 45 67', '1234567', 12 34 56 7' etc.) sodaß wir b) niemals implementieren würden...

Schau dir doch Outlook an, die haben eine witzige Heuristik, um eine Telefonummer zu interpretieren. Das funktioniert sehr gut.

Edit: Ich sehe gerade, hier wird gepostet, was das Zeug hält.

Speichere die Vorwahlen OHNE führende 0 ab. Die internationalen Vorwahlen haben wir so gespeichert, wie sie von Deutschland aus angewählt werden.

Die zu wählende Nummer ist also die Konkatenation der drei Nummern: Die formatierte Nummer ist dann
+IVW (0 OVW) TNR (wenn IVW <> leer)
oder
(0 OVW) TNR (für nationale Gespräche)
oder
TNR für Ortsgespräche.

IVW=Internationale Vorwahl
OVW=Ortsvorwahl
TNR=Telefonnummer

Es gibt sogar eine Norm dafür (ITU?)

Alzaimar, bitte genauer lesen.

hansa hat folgendes geschrieben:

..Ich erhalte z.B. folgende Telefonnummern : 030123450 0301234512345 00352654321 Da ist kein +/- usw. enthalten....(Wird von ISDN-Capi geliefert). Ziel ist es, den Anrufer genauer zu identifizieren, sofern er in DB angelegt ist.

Es geht also um Nummern, die nicht auf Plausibilität geprüft werden müssen !!! Die Telekom nennt so was "Inverssuche". Bei Tippfehlern wird immer noch die Nr. angezeigt, wie gesagt von Capi. Wurde in der DB eine Tel.Nr. eingegeben, die es gar nicht gibt, dann kommt beim falschen Anrufer, also dem, dessen Nr. eigentlich in der DB sein sollte die Anzeige "Anrufer unbekannt". Dann muss diese Nr. eben korrigiert werden.

alzaimar hat folgendes geschrieben:

...Die Stored Procedure kannst du sicherlich in FB selbst programmieren (Du bist ja mit FB verheiratet )...Ich würde: a) Landes- und Ortsvorwahl sowie Telnr getrennt eingeben lassen ODER b) Landes und Ortsvorwahl von der Telnr. trennen und anhand einer Liste die Plausibilität testen. Die deutschen und internationalen Vorwahlen gibts überall im Netz. Wir haben mit a) schon genug Probleme ('123 45 67', '1234567', 12 34 56 7' etc.) sodaß wir b) niemals implementieren würden...

1. Ne, so weit geht die Liebe nicht. Kriege die SP auf Anhieb nicht hin. Syntax scheint bei strings etwas seltsam zu sein. SubStr ? 2. Dein a) und b) verstehe ich nicht. Zumindest nicht im Zusammenhang dit dem von Grenzgenger gesagtem. Soll ich die Nummern nun aufspalten in 3-4 Felder oder nicht ?

Meine Überlegungen gehen eben in die Richtung, aus dem DB-Eintrag 0033-01234/56 78-12 30 folgendes zu machen (also so wie die Capi das liefert) : 0033123456781230 und danach in der DB zu suchen. Weil letzteres ziemlich schlecht zu lesen ist, will ich dem User die Freiheit lassen, die Nr. so einzugeben, wie er will. Bei Ausland wäre dann lediglich die führende 0 bei der Vorwahl wegzumachen.

Performance dürfte kaum eine Rolle spielen, aber wer weiß. Das Programm dient (vorerst) zum Eigenbedarf. Wenn das aber so weiter geht, dann wirds richtig DAU-sicher gemacht und verkauft. Bedarf scheint sogar vorhanden zu sein.

tja, wenn du nach der tel. # suchen willst, dann würd ich einfach zusätzlich die tel# zusammengesetzt abspeichern. die einzelen bestandteile hast dann auch noch im zugriff und kannst dann so aufbereiten, wie es dem jeweiligen user gefällt...

T{volle#, LK#, OK#, W#, dw#) --> DB mit der Vollen# indexiert zum schnellen suchen.

UI: nur LK#, OK#, W#, DW# --> aufbereitung benutzerdefiniert

Grenzgaenger hat folgendes geschrieben:

..dann würd ich einfach zusätzlich die.. T{volle#, LK#, OK#, W#, dw#) --> DB mit der Vollen# indexiert zum schnellen suchen. UI: nur LK#, OK#, W#, DW# --> aufbereitung benutzerdefiniert

Verstehe zwar nur Bahnhof, aber glaube ich weiß, auf was das hinauslaufen soll. Das wird jetzt so gemacht : was als Nr. gespeichert wird ist egal, so wie geplant. Zusätzlich werden die Sonderzeichen direkt im Delphi-Programm entfernt und zusätzlich gespeichert. Die so bereinigte Nummer dient zum Suchen. Was dann angezeigt wird, das ist eine andere Sache. Und fertig.