Making DB -Table on Reactivation -DBDelta -errors on limitations

I work on a plug -in and have an activation hook that makes different tables with DBDelta. The tables are all made without errors or problems. Different tables have foreign key restrictions, all of which also work well.

If I deactivate and respond, however, the last restriction throws the following on each table:

WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'CONSTRAINT  `fk_fkName`  FOREIGN KEY  (`Sour' at line 1 for query ALTER TABLE wp_table ADD COLUMN CONSTRAINT  `fk_fkName`  FOREIGN KEY  (`Source`) REFERENCES wp_other_table (`SourceID`) ON DELETE RESTRICT ON UPDATE RESTRICT

The function mentioned is:

public static function create_table() {

    $sql = "CREATE TABLE " . self::$tbl_table . " (
        `CustomerID` int NOT NULL AUTO_INCREMENT,
        `CompanyName` varchar(50) DEFAULT NULL,
        `FirstName` varchar(50) NOT NULL,
        `LastName` varchar(50) NOT NULL,
        `AddressStreet` varchar(50) NOT NULL,
        `AddressSecond` varchar(50) DEFAULT NULL,
        `AddressCity` varchar(50) NOT NULL,
        `AddressZip` varchar(10) NOT NULL,
        `PhoneNumber` varchar(13) DEFAULT NULL,
        `EmailAddress` varchar(50) DEFAULT NULL,
        `Commercial` bit(1) NOT NULL DEFAULT b'0',
        `Source` int NOT NULL,
        `DoNotTake` bit(1) NOT NULL DEFAULT b'0',
        `Preferred` bit(1) NOT NULL DEFAULT b'0',
        `Notes` varchar(300) DEFAULT NULL,
        PRIMARY KEY  (`CustomerID`),
        CONSTRAINT  `fk_fkName`  FOREIGN KEY  (`Source`) REFERENCES " . self::$tbl_other_table . " (`SourceID`) ON DELETE RESTRICT ON UPDATE RESTRICT

        ) ENGINE=InnoDB;";

    dbDelta($sql);
}

*Table names are obscured out of habit

In that specific table there is only the only limitation and it makes the mistake. In other tables there are only two and no less than five. It is always an error on the last Limitation, and only on activations after the table was first made.

Things I tried:

• Add and remove whitespace around SQL -seeks
• Adding a comma after the last limitation (it was the only real difference between limitations that complain and those who don’t do that)

Here is another example with several FK restrictions:

CONSTRAINT  `fk_fk1`  FOREIGN KEY  (`Field1`) REFERENCES " . self::$tbl_t1 . " (`Field1`) ON DELETE RESTRICT ON UPDATE RESTRICT,
        CONSTRAINT  `fk_fk2`  FOREIGN KEY  (`Field2`) REFERENCES " . self::$tbl_t2 . " (`Field2`) ON DELETE RESTRICT ON UPDATE RESTRICT,
        CONSTRAINT  `fk_fk3`  FOREIGN KEY  (`Field3`) REFERENCES " . self::$tbl_t3 . " (`Field3`) ON DELETE RESTRICT ON UPDATE RESTRICT,
        CONSTRAINT  `fk_fk4`  FOREIGN KEY  (`Field4`) REFERENCES " . self::$tbl_t4 . " (`Field4`) ON DELETE RESTRICT ON UPDATE RESTRICT,
        CONSTRAINT  `fk_fk5`  FOREIGN KEY  (`Field5`) REFERENCES " . self::$tbl_t5 . " (`Field5`) ON DELETE RESTRICT ON UPDATE RESTRICT

*Again, table names and key names are obscured.

Just to repeat, the tables all create well on initial activation with all limitations. In the first example, the mere limitation throws the error for that table when activation/update takes place after the first time (deactivating/activating, updating, everything that the activation hook calls). In the second example (and others) it is only The last limitation that throws the error, and again only after the table already exists and the activation hook is later mentioned.

Because the limitation already exists, DBDelta should ignore it after comparing the table schedule, but for some reason not.