Dies passiert häufig, wenn man graphische Tools wie SSMS zum Tabellendesign verwendet oder seine CREATE TABLE Statements folgendermassen schreibt:

...

CREATE TABLE dbo.Foobar (
    col1 int DEFAULT(0), 
    col2 char(2)
);

Hierbei muss man die DEFAULT Constraint NICHT explizit benennen. Während die folgendeVariante zumindest eine Fehlermeldung auswirft:

CREATE TABLE dbo.Foobar (
    col1 int, 
    col2 char(2)
);

ALTER TABLE dbo.Foobar ADD CONSTRAINT DEFAULT (0) FOR col1;

Msg 156, Level 15, State 1, Line 7
Incorrect syntax near the keyword 'DEFAULT'.

Zwar sieht man nicht auf den ersten Blick, dass das Fehlen des Namens für ein Constraint bemängelt wird, aber früher oder später kommt man doch darauf.

Hat man nun aber aus irgendeinem Grund seine Constraint nicht explizit benannt, generiert SQL Server automatisch einen Namen dafür. Dieser sieht dann so sprechend aus wie "DF__Foobar__col1__6371E77D". Nicht gerade etwas, was man sich leicht merken kann. Will man nun das Versäumnis der Namensgebung rückgängig machen und seine Constraints nun selber mit sprechenderen Namen versehen, kann man diesen systemgenerierten Namen aus sys.default_constraints folgendermassen abfragen:

DECLARE @constraint_name sysname;

SELECT
    @constraint_name = DC.name
FROM
    sys.default_constraints DC
    JOIN
    sys.columns C ON DC.parent_column_id = C.column_id
WHERE
    DC.parent_object_id = OBJECT_ID('dbo.Foobar') AND
    C.name = 'col1';

Zu diesen Zeitpunkt hat die Variable @constraint_name den Wert DF__Foobar__col1__6371E77D. Die Variable kann man anschliessend bequem in ein dynamisches Statement einbauen und ausführen:

IF @constraint_name IS NOT NULL
     EXEC ('ALTER TABLE dbo.Foobar DROP CONSTRAINT ' + @constraint_name);