2016-12-09 3 views
0

Der reguläre Ausdruck, den ich im Design meiner Datenbank für die Überprüfung von E-Mail-Adressen erstellt habe, funktioniert nicht, obwohl ich mehrere Oracle-Foren gelesen habe, die den gleichen Ausdruck verwenden. jedes Mal, wenn ich versuchen, eine E-Mail ich einen Scheck Einschränkungsverletzung erhalten einfügenREGEXP_LIKE (E-Mail funktioniert nicht in Oracle PL SQL

CONSTRAINT check_email CHECK(REGEXP_LIKE(
Email,'^[A-Za-z0-9._-][email protected][A-Za-z0-9._-]+\.[A-Za-z]{2-4}$')) 

wenn EINSÄTZE der Form versucht.?

INSERT INTO Member VALUES(0042, '[email protected]'); 

Kann jemand irgendein Licht in diese Schuppen

Danke!

Antwort

3

Ich habe versucht, Ihr Problem zu replizieren. Das Problem ist die Verwendung von '-' in Ihrem Bereich für die letzten Alphabete nach dem Zeitraum. Verwenden Sie stattdessen ein Komma.

Bedenken Sie:

Tabelle:

CREATE TABLE abc_1(abc_id NUMBER(10), email VARCHAR2(100)); 

Constraint (gleiche wie Sie):

ALTER TABLE abc_1 ADD CONSTRAINT abc_email_check CHECK(REGEXP_LIKE(Email,'^[A-Za-z0-9._-][email protected][A-Za-z0-9._-]+\.[A-Za-z]{2-4}$')); 

Insert Statement:

INSERT INTO abc_1 VALUES (1001, '[email protected]'); --Fails, expected 
    INSERT INTO abc_1 VALUES (1001, '[email protected]'); --Fails, not expected 

Das Problem ist mit dem Bereich Spezifikation {2-4} . Welche eher sein sollte {2,4} Ihre Check-Einschränkung ersetzen als:

ALTER TABLE abc_1 ADD CONSTRAINT abc_email_check CHECK(REGEXP_LIKE(Email,'^[A-Za-z0-9._-][email protected][A-Za-z0-9._-]+\.[A-Za-z]{2,4}$')); 

    INSERT INTO abc_1 VALUES (1001, '[email protected]'); --Fails, expected 
    INSERT INTO abc_1 VALUES (1001, '[email protected]'); --Success, expected 

Wenn in regulärem Ausdruck spezifiziert Bereich, ist der Weg {m, n}, wobei m untere Grenze und n die Obergrenze sein .

+0

'@ [A-Za-z0-9 ._-] +. [A-Za-z] {2,4} $' ist nicht ausreichend, denke an TLDs wie [.museum] (https://en.wikipedia.org/wiki/.museum) zum Beispiel. –

+0

@WernfriedDomscheit - das ist richtig, aber es sollte ein Kommentar zum OP sein, nicht zu diesem Befragten. Rogue Coder hat den Fehler im OP-Code korrekt erkannt. Ob das "n" in {m, n} größer als 4 sein sollte, ist eine Geschäftsfrage, keine Codierungsfrage. (Wer weiß, vielleicht hat das OP einen Grund, das letzte Token auf 4 Zeichen zu beschränken - und in jedem Fall steht das nicht im Zusammenhang mit dieser Antwort.) – mathguy

+0

stimmte den beiden Kommentaren zu. Offensichtlich eine E-Mail-ID, die mit '.' sieht komisch aus, aber wer weiß! –