I'm looking to get clarity on this issue/bug for better handling future DB changes to a custom plugin. I have a plugin that creates about 10 tables. 3 of them have foreign keys to multiple other tables. When the tables are created using dbDelta, they are all created successfully and the foreign keys are exactly as defined, but it kicks back a generic error: 1064 "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use". Looking at MariaDB's docs for foreign keys, the syntax looks correct: Foreign Keys - MariaDB KB WP Version: 6.6.2 MariaDB Version: 15.1 Distrib 10.11.6 Here's a sample of one of the tables that has foreign keys: $sql = "CREATE TABLE $ads_tracker_table_name ( uid bigint(20) unsigned NOT NULL auto_increment, siteid int(10) unsigned NOT NULL, adid int(10) unsigned NOT NULL, activityid bigint(20) unsigned NOT NULL, typeid tinyint(3) unsigned NOT NULL, time datetime DEFAULT '0000-00-00 00:00:00' NOT NULL, FOREIGN KEY (adid) REFERENCES $ads_table_name(uid) ON DELETE CASCADE, FOREIGN KEY (activityid) REFERENCES $tracker_table_name(uid) ON DELETE CASCADE, FOREIGN KEY (typeid) REFERENCES $ads_event_types_table_name(uid) ON DELETE CASCADE, PRIMARY KEY (uid), INDEX siteid_index (siteid), INDEX adid_index (adid), INDEX activityid_index (activityid), INDEX typeid_index (typeid) ) $charset_collate;"; dbDelta( $sql ); Here's the strange part: Out of all 3 tables with foreign keys, it only kicks out the 1064 error for the LAST foreign key for each table. Using the example table above, the first two foreing keys (adid) and (activityid) do NOT return the error, but (typeid) does. If I switch the order and move (typeid) up and something else as the last foreign key statement, the (typeid) does NOT return the 1064 error, but the new last foreign key statement always does. The keys are created, but I can't get rid of this returned 1064 error and it's really driving me crazy. Looking at how dbDelta is handling the $sql var thrown at it, it breaks it down into separate queries. One to create the table without foreign keys, and then one to alter the table to add the foreign keys. The specific dbDelta query failing is the second one to add the foreign keys: ALTER TABLE prefix_ads_tracker ADD FOREIGN KEY (typeid) REFERENCES prefix_ads_event_types(uid) ON DELETE CASCADE It adds the keys successfully and correctly, but returns the 1064 error. Copy/pasting that SQL ALTER statement above directly in phpMyAdmin executes successfully without any errors. Same result whether there's 1 space after FOREIGN KEY, or 2 spaces like the PRIMARY KEY. I've also tried setting up the foreign keys with CONSTRAINT and got the same results....added successfully and correctly, but returned the 1064 error. CONSTRAINT EG: CONSTRAINT att_typeid FOREIGN KEY (typeid) REFERENCES $ads_event_types_table_name(uid) ON DELETE CASCADE, My question: is there a way to get dbDelta to NOT kick back generic errors for operations it completes successfully? Is there something I can do to my SQL statements to work better with dbDelta? Is this a bug I should be reporting to the WP tracker? Sorry for being long-winded, but trying to anticipate and answer any questions before they're asked. There are a lot of 1064 error questions related to Foreign Keys and dbDelta, but most are fairly old, none with this level of detail, and none for this specific issue. Thanks in advance for your input!