MySQL 1050 Fehler "Tabelle existiert bereits", obwohl dies nicht der Fall ist

Ich füge diese Tabelle hinzu:

CREATE TABLE contenttype (
        contenttypeid INT UNSIGNED NOT NULL AUTO_INCREMENT,
        class VARBINARY(50) NOT NULL,
        packageid INT UNSIGNED NOT NULL,
        canplace ENUM('0','1') NOT NULL DEFAULT '0',
        cansearch ENUM('0','1') NOT NULL DEFAULT '0',
        cantag ENUM('0','1') DEFAULT '0',
        canattach ENUM('0','1') DEFAULT '0',
        isaggregator ENUM('0', '1') NOT NULL DEFAULT '0',
        PRIMARY KEY (contenttypeid),
        UNIQUE KEY packageclass (packageid, class)
);

Und ich bekomme eine 1050 "Tabelle existiert bereits"

Aber die Tabelle existiert NICHT. Irgendwelche Ideen?

EDIT: mehr Details, weil mir jeder nicht zu glauben scheint :)

DESCRIBE contenttype

Ausbeuten:

1146 - Tabelle 'gunzfact_vbforumdb.contenttype' existiert nicht

und

CREATE TABLE gunzfact_vbforumdb.contenttype(
contenttypeid INT UNSIGNED NOT NULL AUTO_INCREMENT ,
class VARBINARY( 50 ) NOT NULL ,
packageid INT UNSIGNED NOT NULL ,
canplace ENUM( '0', '1' ) NOT NULL DEFAULT '0',
cansearch ENUM( '0', '1' ) NOT NULL DEFAULT '0',
cantag ENUM( '0', '1' ) DEFAULT '0',
canattach ENUM( '0', '1' ) DEFAULT '0',
isaggregator ENUM( '0', '1' ) NOT NULL DEFAULT '0',
PRIMARY KEY ( contenttypeid ) ,

Ausbeuten:

1050 - Tabelle 'Inhaltstyp' existiert bereits

Klingt so, als hätten Sie Schrödingers Tisch ...

Im Ernst, Sie haben wahrscheinlich einen kaputten Tisch. Versuchen:

• DROP TABLE IF EXISTS contenttype
• REPAIR TABLE contenttype
• Wenn Sie über ausreichende Berechtigungen verfügen, löschen Sie die Datendateien (in / mysql / data / db_name).

aus dem MySQL-Protokoll:

InnoDB: You can drop the orphaned table inside InnoDB by
InnoDB: creating an InnoDB table with the same name in another
InnoDB: database and copying the .frm file to the current database.
InnoDB: Then MySQL thinks the table exists, and DROP TABLE will
InnoDB: succeed.

Möglicherweise müssen Sie den Tabellencache leeren. Zum Beispiel:

DROP TABLE IF EXISTS `tablename` ;
FLUSH TABLES `tablename` ; /* or exclude `tablename` to flush all tables */
CREATE TABLE `tablename` ...

Ich habe den gleichen Fehler erhalten und REPAIR TABLE (aus der Antwort von @ NullUserException) hat nicht geholfen.

Ich fand schließlich diese Lösung :

sudo mysqladmin flush-tables

Für mich ohne das habe sudoich folgenden Fehler bekommen:

mysqladmin: refresh failed; error: 'Access denied; you need the RELOAD privilege for this operation'

(Läuft unter OS X 10.6)

Ich habe den ganzen Tag damit gekämpft: Ich habe ein Perl-Skript, das eine Reihe von Tabellen erstellt, indem es zuerst eine DROP IF EXISTS ...auf sie macht und sie dann CREATEbearbeitet. Das ist DROPgelungen, aber am habe CREATEich folgende Fehlermeldung bekommen: table already exists

Endlich bin ich dem auf den Grund gegangen: Die neue Version von MySQL, die ich verwende, hat eine Standard-Engine von InnoDB ("show engine \ G;"). Ich habe sie in der Datei my.cnf so geändert, dass sie standardmäßig MyISAM ist. hat MySQL gestartet und jetzt erhalte ich nicht mehr den Fehler "Tabelle existiert bereits".

Das gleiche Problem trat bei mir beim Erstellen einer Ansicht auf. Die Ansicht war früher vorhanden, als sie aufgrund einiger Änderungen entfernt wurde. Als ich jedoch versuchte, sie erneut hinzuzufügen, wurde die Fehlermeldung "Ansicht existiert bereits" angezeigt.

Lösung :

Sie können eine Sache manuell tun.

1. Wechseln Sie in den MySQL-Ordner, in dem Sie ihn installiert haben
2. Gehen Sie zum darin enthaltenen Datenordner.
3. Wählen Sie Ihre Datenbank und gehen Sie hinein.
4. Die Datenbank erstellt Dateien im ".frm" -Format.
5. Löschen Sie die Datei der jeweiligen Tabelle.
6. Erstellen Sie nun die Tabelle erneut.

Die Tabelle wird erfolgreich erstellt.

Wenn ich auf dasselbe Problem stoße (InnoDB-Tabelle erstellen), hat dies für mich endlich funktioniert:

DROP DATABASE `having_issues`;

Ich überprüfte auf Dateibasis, Berechtigungen, versuchte zu REPARIEREN und SPÜLEN, aber nichts funktionierte.

Wenn dies eine Option ist, verschieben Sie alle Arbeitstabellen in eine andere DATENBANK, löschen Sie die alte (möglicherweise müssen Sie alle Dateien manuell aus dem Datenbankordner entfernen, bevor sie gelöscht werden) , benennen Sie die neue um und Sie sollten es sein zurück auf dem Weg. Anscheinend wird alles, was mit InnoDB zwischengespeichert wird, zusammen mit der Originaldatenbank gelöscht.

Ich hatte dieses Problem unter Win7 in SQL Maestro für MySQL 12.3. Enorm irritierend, ein Show-Stopper in der Tat. Nichts half, nicht einmal das Löschen und Neuerstellen der Datenbank. Ich habe das gleiche Setup unter XP und es funktioniert dort. Nachdem ich Ihre Antworten zu Berechtigungen gelesen hatte, wurde mir klar, dass es sich um Win7-Berechtigungen handeln muss. Also habe ich MySql als Administrator ausgeführt und obwohl Sql Maestro normal ausgeführt wurde, ist der Fehler verschwunden. Es muss also ein Berechtigungsproblem zwischen Win7 und MySql gewesen sein.

Ich bin auch auf dieses Problem gestoßen, bei dem beim Erstellen einer Tabelle festgestellt wurde, dass sie bereits vorhanden ist, und beim Löschen der Tabelle angegeben wurde, dass sie nicht vorhanden ist.

Ich habe "FLUSH TABLES" gemacht und das Problem wurde behoben.

Ich kämpfe mit dem gleichen Problem. Ich kann keine Tabelle erstellen, obwohl sie nicht vorhanden ist. Ich habe alle oben genannten Lösungen ohne Erfolg ausprobiert.

Meine Lösung war , die Dateien zu löschen ib_logfil0, ib_logfile1, ibdata1, und auto.cnfaus dem Datenverzeichnis von MySQL; Stellen Sie sicher, dass Sie den MySQL-Dienst zuerst beenden, bevor Sie diese Dateien löschen.

Nach dem Neustart des Dienstes hat MySQL diese Dateien neu erstellt und ich konnte ein Sicherungsskript ausführen, in dem alle meine Dateien CREATEgespeichert waren (eine sqldump-Datei).

Überprüfen Sie zuerst, ob Sie sich in der richtigen Datenbank befinden USE yourDBund versuchen Sie Select * from contenttypenur zu sehen, was es ist und ob es wirklich existiert ...

Ich hatte das gleiche Problem unter Mac OS X und MySQL 5.1.40. Ich habe mein SQL-Skript mit Eclipse bearbeitet und dann MySQLWorkbench 5.2.28 ausprobiert. Wahrscheinlich wurden Zeilenumbrüche in das Mac-Format konvertiert. Ich hatte keine Ahnung, was mit meinem Skript nicht stimmt, bis ich die erste Zeile in der Datei auskommentierte. Danach wurde dieses Skript von MySQL als ein einziger Kommentar interpretiert. Ich habe die integrierte TextEdit Mac-Anwendung verwendet, um dies zu beheben. Nachdem Zeilenumbrüche in das richtige Format konvertiert wurden, ist der Fehler 1050 verschwunden.

Update für Eclipse-Benutzer:

So richten Sie die Standardende für neu erstellte Dateien im gesamten Arbeitsbereich ein:

Fenster -> Einstellungen -> Allgemein -> Arbeitsbereich -> Zeilenbegrenzer für neue Textdateien.

Um vorhandene Dateien zu konvertieren, öffnen Sie die Datei zum Bearbeiten und gehen Sie für die aktuell bearbeitete Datei zum Menü:

Datei -> Zeilenbegrenzer konvertieren in

Ich hatte den gleichen Fall. Das Problem waren schließlich Berechtigungen für das übergeordnete Verzeichnis.

Ich hatte während des Testens Dateien in MySQL und aus MySQL kopiert.

drwx------   3 _mysql  wheel 

war nicht genug, musste sein:

-rw-rw----   3 _mysql  wheel 

Tut mir leid, wieder auferstehen zu müssen.

Ich hatte große Probleme mit den Fehlern 1050 und 150.

Das Problem für mich war, dass ich versuchte, eine Einschränkung ON DELETE SET NULLals eine der Bedingungen hinzuzufügen .

Durch Ändern auf ON DELETE NO ACTIONkonnte ich die erforderlichen FK-Einschränkungen hinzufügen.

Leider sind die MySQL-Fehlermeldungen absolut nicht hilfreich, so dass ich diese Lösung iterativ und mithilfe der Antworten auf die obige Frage finden musste.

Ich hatte das gleiche Problem und es sieht so aus, als ob der Name der Datenbank zwischen Groß- und Kleinschreibung unterscheidet. Meine Datenbank heißt:

Mydatabase

Während mein Skript enthalten

USE mydatabase

Nachdem ich den Datenbanknamen in den richtigen Fall geändert hatte, schien alles zu funktionieren. Verwenden von MYSQL Workbench unter MAC OSX

Dieses Problem tritt auch auf, wenn in der Datenbank eine 'Ansicht' (imaginäre Tabelle) mit demselben Namen wie unser neuer Tabellenname vorhanden ist.

In meinem Fall stellte ich fest, dass dies ein Problem mit InnoDB ist. Ich habe nie herausgefunden, was das eigentliche Problem war, aber das Erstellen als MyISAM ermöglichte das Erstellen

Für mich wurde das Problem verursacht, wenn anstelle von mysqldump eine Dateisystemkopie des MySQL-Datenbankverzeichnisses verwendet wurde. Ich habe einige sehr große Tabellen, hauptsächlich MyISAM und einige InnoDB-Cache-Tabellen, und es ist nicht praktisch, die Daten zu mysqldumpen. Da wir immer noch MyISAM ausführen, ist XtraBackup keine Option.

Die gleichen Symptome wie oben sind mir passiert. Die Tabelle ist nicht vorhanden, es befinden sich keine Dateien im Verzeichnis, die sich auf die Tabelle beziehen. Sie kann jedoch nicht erstellt werden, da MySQL glaubt, dass sie vorhanden ist. Drop-Tabelle sagt, dass es nicht da ist, Create-Tabelle sagt, dass es da ist.

Das Problem trat auf zwei Computern auf. Beide wurden durch Kopieren von Sicherungen behoben. Ich habe jedoch festgestellt, dass in meiner Sicherung eine .MYD- und .MYI-Datei vorhanden war, obwohl ich den Eindruck hatte, dass diese Dateien nicht für InnoDB verwendet werden. Die .MYD- und .MYI-Dateien hatten einen Eigentümer von root, während die .frm im Besitz von mysql war.

Wenn Sie aus dem Backup kopieren, überprüfen Sie die Dateiberechtigungen. Flush-Tabellen funktionieren möglicherweise, aber ich habe mich dafür entschieden, die Datenbank herunterzufahren und neu zu starten.

Viel Glück.

Meine Güte, ich hatte das gleiche Problem mit dem osCommerceInstallationsskript, bis ich herausfand, dass das MySQL-System viele Datenbanken hat und die create tableAbfrage sich in jede kopiert. Daher half es nicht, nur die Arbeitstabelle auf der aktiven Datenbank zu löschen. Ich musste die Tabelle aus allen Datenbanken löschen

Meine CREATE-Anweisung war Teil der Bereitstellung von env dump.

Ich habe alles versucht, was oben erwähnt wurde. Ich habe keine Lösung bekommen. Mein Weg zur Erlösung war jedoch:

1. Ich stolpere über die Tatsache, dass (eine von vielen in) die CREATE-Anweisung durchgekommen ist, als ich die Groß- und Kleinschreibung des Datenbanknamens korrigiert habe. Dies klickte etwas. Ich wiederholte das gleiche für die anderen Tische.

2. Es kam jedoch ein neuer Fehler in die Szene. Die geraden Anführungszeichen für 'Kommentare' haben einen Syntaxfehler ausgelöst. Ich war schockiert. ersetzte sie, aber der neue Fehler tauchte auf. Endlich wusste ich die Lösung.

LÖSUNG: Der von mir verwendete Speicherauszug stammt möglicherweise aus einer anderen Version von MySql. Ich habe die Berechtigung erhalten, über die lokale (auf meinem Computer installierte) MySQL-Workbench eine Verbindung zum Staging MYsql herzustellen. Ich habe mich nicht auf dem Staging-Server angemeldet, um mich bei der Staging-MySQL-Workbench anzumelden. Von dort aus wurde ein Dump erstellt. Lief die Müllkippe und es funktionierte wie eine Süßigkeit.

Ich habe versucht, eine Backup-SQL-Datei zu importieren, habe aber den Fehler erhalten. 1050 "Tabelle existiert bereits"

Mein Setup war:

• Windows 7
• MySQL 5.5.16

Lösung:

1. Die Server-Engine wurde von InnoDB in MyISAM geändert
2. Verwenden von phpMyAdmin Löschte die Datenbank, in die ich importieren wollte
3. Starten Sie den MySQL-Dienst neu
4. Versuchte die Wiedereinfuhr und es funktionierte

Ihre Festplatte ist möglicherweise auch nur voll. (hatte gerade das)

In meinem Fall bestand das Problem darin, dass es eine Ansicht mit demselben Namen wie meine Tabelle gab, sodass ich die Ansicht löschen musste, damit der Import fortgesetzt werden konnte.

drop view `my-view-that-has-same-name-as-table`;

Eine automatisierte Lösung, die für mich funktioniert hat, besteht darin, die normale Drop-Tabelle während des Dumps durch diese Sed zu ersetzen, um auch eventuell vorhandene Ansichten zu löschen:

mysqldump my-db \
| sed -E 's/^DROP TABLE IF EXISTS(.+)$/\0 DROP VIEW IF EXISTS\1/g' \
| mysql my-other-db

Oder wenn Sie lieber zur Sicherung in eine Datei drucken möchten

mysqldump my-db \
| sed -E 's/^DROP TABLE IF EXISTS(.+)$/\0 DROP VIEW IF EXISTS\1/g' \
> my-db.dump.sql

Oder wenn Sie die abgelegte Datei erhalten haben und sie in Ihre Datenbank importieren

cat my-db.dump.sql \
| sed -E 's/^DROP TABLE IF EXISTS(.+)$/\0 DROP VIEW IF EXISTS\1/g' \
| mysql my-other-db

Du hast die Idee

Hinweis: Es ist wichtig, dass Sie den ^am Anfang des Ersatz-Regex enthaltenen Befehl hinzufügen , da es DROP TABLE IF EXISTSin Dumps andere Arten von Befehlen gibt, die Sie nicht berühren möchten.

Sie haben so etwas nicht mehr:

--
-- Table structure for table `my_table`
--

DROP TABLE IF EXISTS `my_table`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `my_table` (
...

Um so etwas zu haben:

--
-- Table structure for table `my_table`
--

DROP TABLE IF EXISTS `my_table`; DROP VIEW IF EXISTS `my_table`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `my_table` (
...

Du wirst mir nicht glauben! Ich habe gerade einen Kommentarblock aus meiner .sql-Datei entfernt und jetzt funktioniert es.

CREATE DATABASE  IF NOT EXISTS `issga` /*!40100 DEFAULT CHARACTER SET utf8 */;
USE `issga`;
--
-- Table structure for table `protocolo`
--

DROP TABLE IF EXISTS protocolo;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
 CREATE TABLE protocolo (
  `idProtocolo` int(11) NOT NULL AUTO_INCREMENT,
  `tipo` varchar(30) DEFAULT NULL,
  `estado` int(2) DEFAULT 0,
  PRIMARY KEY (`idProtocolo`)
 ) ENGINE=InnoDB AUTO_INCREMENT=142 DEFAULT CHARSET=utf8;
 /*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `protocolo`
--

LOCK TABLES protocolo WRITE;
/*!40000 ALTER TABLE protocolo DISABLE KEYS */;
/* INSERT INTO `protocolo` VALUES () */
/*!40000 ALTER TABLE protocolo ENABLE KEYS */;
UNLOCK TABLES;

Der gelöschte Kommentarblock war folgender:

--
-- Table structure for table `protocolo`
-- 

Ich habe die problematische Tabelle in derselben SQL-Datei alleine gelassen. Danach habe ich Kommentare entfernt, der einzige Code war übrig und der Fehler verschwindet.

Ich hatte gerade den gleichen Fehler, aber ich wusste, dass die Tabelle bereits existiert und wollte sie ergänzen. Ich füge meine Antwort hinzu, da diese Frage bei Google als Nr. 1 für mich angezeigt wird, wenn nach demselben Fehler gesucht wird, jedoch nach einem etwas anderen Szenario. Grundsätzlich musste ich ankreuzen

"Fügen Sie die Anweisung DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER hinzu."

Und das hat den Fehler für mich gelöst.