Announcement

Collapse
No announcement yet.

Index Expressions

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Index Expressions

    Bei einer Umstellung von Firebird 2 auf MS SQL 2005 bin ich auf folgendes Problem gestoßen. ich möchte einen unique Index der Art

    CREATE UNIQUE INDEX <IndexName> ON <Table> COMPUTED BY (UPPER(<VarCharField))

    anlegen, um ein Einfügen von doppelten Records zu vermeiden. Bis jetzt habe ich mir mit dem Anlegen einer "COMPUTED BY" - Spalte <Name> ("LTrim(RTrim(Upper(<Name>)))") mit einem Unique-Index beholfen.

    Geht es nicht vielleicht auch etwas eleganter (mit weniger Speichebedarf) in MS SQL 2005 ?

  • #2
    Hallo,

    warum so umständlich? Beim MS SQL Server reicht die folgende Deklaration aus:

    [highlight=SQL]
    USE tempdb
    GO

    CREATE TABLE dbo.TestTbl
    (
    testtbl_id INT NOT NULL IDENTITY PRIMARY KEY,
    testwert VARCHAR(9) NOT NULL UNIQUE,
    )
    GO
    INSERT INTO dbo.TestTbl (testwert) VALUES ('bernd')
    INSERT INTO dbo.TestTbl (testwert) VALUES ('Bernd')
    [/highlight]

    Der 2. INSERT-Aufruf mit der anderen Schreibweise des gleichen Namens löst das Veto 2627 aus:

    -- Msg 2627, Level 14, State 1, Line 1
    Verletzung der UNIQUE KEY-Einschränkung 'UQ__TestTbl__78BFA819'. Ein doppelter Schlüssel kann in das 'dbo.TestTbl'-Objekt nicht eingefügt werden.
    Die Anweisung wurde beendet.

    Comment


    • #3
      Hallo,

      offensichtlich verhalten sich Firebird & SQL 2005 bei den definierten Unique-Fields unterschiedlich. Ich dachte, das zumindestens ein gleiches Verhalten bei den Standard-SQL-Anweisungen zu erwarten sei.

      Ihr Beispiel fügt unter Firebird nämlich beide Records ein, während der MS SQL Server sein Veto einlegt.

      Danke für den Hinweis.

      Comment


      • #4
        Hallo Thomas,

        das kann unter SQL Server über die COLLATION eine (var)char Feldes gesteuert werden.
        Im Standard werden unter SQL Server die DBs und somit auch die Felder mit einer Case Insensitive Collation angelegt; da ist Groß-/Kleinschreibung gleichwertig und somit löst hier das Insert eine PK Fehler aus.
        Wenn Du das Feld (oder ganze DB) auf eine Case Sensitive Collation umstellst, hast Du das gleiche Verhalten wie bei Deiner Firebird DB.

        Olaf.
        Olaf Helper

        <Blog> <Xing>
        * cogito ergo sum * errare humanum est * quote erat demonstrandum *
        Wenn ich denke, ist das ein Fehler und das beweise ich täglich

        Comment

        Working...
        X