A database import with phpMyAdmin can fail for various reasons. The SQL file may be too large, the import may abort during processing, or MySQL may output a specific error message regarding tables, permissions, character sets, or existing records.
It is important not to restart the same process immediately after a failed import. A canceled import may have already created some of the tables and data. A second import over this intermediate state can cause additional errors.
In this guide, we will show you how to systematically analyze a failed phpMyAdmin import, categorize typical error messages, and decide how to proceed safely.
Important: Note down or copy the complete error message before you change anything. The exact message is much more helpful for error analysis than the general information that the import „does not work“.
First, determine at which point the import fails #
Not every import error has the same cause. Therefore, first check what exactly happened.
Typical situations are:
- the SQL file cannot be selected or uploaded at all
- phpMyAdmin reports an error even before the actual import
- the import starts, but aborts during processing
- phpMyAdmin displays a specific MySQL or SQL error message
- The import is reported as successful, but the website does not work afterward.
- part of the tables was imported, the rest is missing
These cases must be treated differently.
Check the database status before a new attempt #
Open the relevant target database in phpMyAdmin and check if tables already exist.
If an empty database existed before the import and tables are now displayed, at least part of the SQL file was processed.
Attention: Do not simply restart a failed import over a partially imported database. This can cause errors due to already existing tables or duplicate records.
Read the error message completely #
phpMyAdmin or the database server provides a specific message for many problems.
Note:
- Error number, if available
- full error text
- affected table
- affected SQL statement, if displayed
- approximate point where the import was interrupted
A screenshot of the complete message can also be helpful for a later analysis.
The SQL file is larger than the allowed upload limit #
If phpMyAdmin only accepts files up to a certain size, a larger SQL file cannot be imported via the normal upload.
Depending on the server configuration, the import page can display a maximum allowable file size.
If your SQL file is larger than this limit, the problem is not automatically the database itself. The file may not even reach phpMyAdmin completely.
Important: Do not change PHP limits randomly. First, check which limit is actually being reached and whether the setting in question should even be changed by yourself in your hosting environment.
Compress SQL file #
Depending on the phpMyAdmin and server configuration, compressed SQL files may be supported.
A file like:
database.sql
can be significantly compressed depending on the data content.
A supported compressed variant could look like this, for example:
database.sql.gz
You can determine if and which compression formats are accepted by looking at the import interface or the specific server configuration.
However, compression only helps with a size issue of the transferred file. It does not solve SQL, permission, or table errors.
Import started, but it is timing out #
For large or complex SQL files, the import can start and later fail due to a time limit.
This differs from a pure upload limit: the file was accepted and at least partially processed.
In this case, be sure to check whether tables and records already exist in the target database.
Browser shows a blank page or connection drops #
If the browser no longer displays a normal success message during a long import, that does not automatically mean that nothing was imported at all.
Then open the target database again in phpMyAdmin and check its status.
Do not restart the import until it has been clarified what has already been processed.
Partially imported database #
SQL files are typically processed statement by statement. If the process is aborted in the meantime, the previous statements may have already been executed.
The target database can then look like this, for example:
Table A → available
Table B → available
Table C → available
Table D → import aborted here
further tables → missingSuch a database is no longer empty, but may not be complete either.
Important: Treat a canceled import as a potential intermediate state. Check the database first before deleting, re-importing, or using the website productively with it.
Start fresh or continue import? #
Which procedure is correct depends on the SQL file, the error, and the state of the target database.
For a newly created database intended exclusively for this migration, a clean restart may make more sense than attempting to manually resume an unclear partial import.
If the database, on the other hand, already contains production data, you must under no circumstances simply delete existing tables.
Attention: Only delete or reset a partially imported database if it is certain that it contains no required productive data and a suitable initial backup exists.
Error #1044 – Access to the database denied #
An error message with an error number #1044 typically indicates a permission issue related to a database.
This can occur, for example, when the SQL file attempts to use or create a database for which the current database user or hosting account does not have the necessary privileges.
Check in particular whether the SQL file contains statements such as:
CREATE DATABASE ...
USE ...contains and whether these match the target environment.
Why CREATE DATABASE can be problematic in hosting #
In a cPanel hosting environment, databases are usually created via cPanel and assigned to the hosting account.
An imported SQL file should therefore not attempt to create arbitrary new databases at the server level without being checked.
Create the required target database instead as in Create MySQL database in cPanel described and then import the data into this database.
USE statement refers to an old database name #
An SQL file from another hosting environment may contain an earlier database name.
For example:
USE alteraccount_wordpress;At the new location, on the other hand, the database can, for example:
newaccount_wordpress
be called.
Such a deviation can be relevant during import.
Attention: Do not blindly remove or modify SQL statements. First, check which statements are present, what they do, and which target database is actually supposed to be used.
Error #1045 – Access denied #
Error #1045 typically represents a failed authentication or denied database access.
If the error occurs in connection with an application, check:
- complete database username
- Database user password
- Database host
- Assigning the user to the database
- User permissions
We explain how to properly set up a database user at Create MySQL user and assign to a database.
Import was successful, but the website still reports #1045 or "Access denied" #
In this case, the database may be completely imported and only the application is using incorrect access credentials.
In WordPress, you should then pay particular attention to the values in:
wp-config.php
check.
These include:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOSTReimporting the database does not fix incorrect application credentials.
Error #1050 – Table already exists #
A message like:
#1050 - Table already exists
means that the SQL file wants to create a table that already exists in the target database.
This frequently occurs when:
- an import has already been partially carried out
- the same import was started a second time
- the target database was not empty before the import
- another installation is already using the same table names
Do not immediately delete tables for #1050 #
First, check why the table already exists.
If it is a production table, deleting it could cause data loss.
If, on the other hand, the database was created exclusively for a new migration and an initial import has demonstrably failed, a clean restart can be a viable approach.
The decision depends on the actual state of the database.
Error #1062 – Duplicate entry #
Error #1062 typically indicates that a value should be inserted that already exists due to a unique key.
For example, a message can essentially be:
Duplicate entry
point out.
This can occur, among other things, when data has already been imported and is then to be inserted again.
Why a second import can cause #1062 #
If the initial import has already created records, a repeated import may attempt to insert the same IDs or other unique values again.
The database prevents this if corresponding uniqueness rules are defined.
Important: A
#1062An error is no reason to remove unique keys on suspicion. These are part of the database structure and can be crucial for the correct functioning of the application.
Error #1064 – SQL syntax error #
Error #1064 typically indicates an SQL statement that cannot be processed in this form by the database server.
Possible causes can be:
- a damaged or incomplete SQL file
- a manually incorrectly modified SQL statement
- incompatible syntax
- an issue at a specific location in the export file
The error message often names a location or a section near which the error was detected.
Do not randomly delete lines in case of syntax errors #
A seemingly problematic line can be part of a larger SQL statement.
If you remove individual lines on a hunch, the file may fail at another point afterwards or import incomplete data.
First check the exact error message and the origin of the SQL file.
Error due to unknown collation #
When importing a database from another server environment, a message may appear stating that a specific collation is unknown or not supported.
This can happen, for example, if the source and destination use different database server versions or different supported collations.
The error message may essentially contain:
Unknown collation
Do not blindly replace collation #
There are numerous guides on the internet that recommend replacing a collation across the entire SQL file with another one wholesale.
That can work in a specific case, but it is not a universal solution.
Check first:
- which collation the source database uses
- which collation the target server supports
- which character set is associated with it
- whether the application has special requirements
Attention: Character set and collation affect the storage and processing of text. Ill-considered changes can lead to incorrectly displayed characters or unexpected comparison and sorting behavior.
Umlauts and special characters are incorrect after the import #
Wenn Zeichen wie:
ä
ö
ü
é
ànach dem Import falsch dargestellt werden, kann ein Zeichensatzproblem vorliegen.
Prüfe, ob das Problem bereits in der SQL-Datei vorhanden ist oder erst nach dem Import auftritt.
Ändere nicht sofort die gesamte Datenbankkollation. Die Ursache kann an unterschiedlichen Stellen der Export- und Importkette liegen.
Fehler wegen unbekanntem Zeichensatz #
Auch ein nicht unterstützter Zeichensatz kann einen Import verhindern.
In diesem Fall sollte zuerst geklärt werden, mit welchem Datenbanksystem beziehungsweise welcher Version die SQL-Datei erzeugt wurde und welche Zeichensätze das Zielsystem unterstützt.
Fehler bei DEFINER-Anweisungen #
SQL-Exporte können bei bestimmten Datenbankobjekten Angaben zu einem DEFINER contain.
Diese können auf einen Benutzer der ursprünglichen Serverumgebung verweisen, der auf dem Zielsystem nicht existiert beziehungsweise dort nicht verwendet werden darf.
Beispielsweise kann eine SQL-Datei einen serverbezogenen Benutzer enthalten, der nur auf dem bisherigen System vorhanden war.
Wenn eine Fehlermeldung ausdrücklich auf DEFINER oder entsprechende Berechtigungen verweist, sollte genau dieser Teil der SQL-Datei beziehungsweise der betroffenen Datenbankobjekte geprüft werden.
Important: Entferne nicht pauschal sämtliche
DEFINER-Angaben aus jeder SQL-Datei. Prüfe zuerst, welche Objekte betroffen sind und ob diese für die Anwendung benötigt werden.
Fehler wegen fehlender Berechtigungen #
Ein SQL-Export aus einer Umgebung mit weitreichenden Datenbankrechten kann Anweisungen enthalten, die in einer normalen Hosting-Umgebung nicht zulässig sind.
Das bedeutet nicht automatisch, dass dein Hosting-Account falsch konfiguriert ist.
Bestimmte serverweite administrative Aktionen sind bei Shared Hosting bewusst nicht für einzelne Hosting-Accounts freigegeben.
Import bricht bei einer bestimmten Tabelle ab #
Wenn der Fehler immer bei derselben Tabelle auftritt, notiere:
- Tabellenname
- Fehlernummer
- Error message
- ungefähre Position innerhalb des Imports
Damit lässt sich wesentlich gezielter unterscheiden, ob beispielsweise die Tabellenstruktur, ein Datensatz oder eine nicht unterstützte SQL-Anweisung das Problem verursacht.
Import bleibt scheinbar bei einer großen Tabelle hängen #
Einzelne Tabellen können sehr viel größer sein als der Rest einer Datenbank.
Bei WordPress können beispielsweise Protokoll-, Statistik-, Cache- oder andere von Erweiterungen angelegte Tabellen erhebliche Datenmengen enthalten.
Breche einen Import nicht allein deshalb ab, weil eine große Tabelle länger benötigt.
Prüfe, ob phpMyAdmin tatsächlich einen Fehler meldet oder der Vorgang noch verarbeitet wird.
Sehr große SQL-Dateien aufteilen? #
Das Aufteilen einer SQL-Datei kann in bestimmten Situationen eine technische Lösung sein, sollte aber nicht durch willkürliches Zerschneiden an beliebigen Stellen erfolgen.
SQL-Anweisungen können sich über viele Zeilen erstrecken. Wird eine Anweisung mitten im Befehl getrennt, entstehen ungültige Dateien.
Attention: Teile große SQL-Dateien nur mit einem dafür geeigneten Verfahren beziehungsweise ausreichenden SQL-Kenntnissen auf. Ein normaler Texteditor und eine beliebige Zeilennummer sind dafür keine sichere Methode.
SQL-Datei ist möglicherweise unvollständig #
Wenn bereits der ursprüngliche Export abgebrochen wurde, kann die erzeugte SQL-Datei unvollständig sein.
Ein späterer Import kann dann ebenfalls abbrechen, obwohl mit der Zieldatenbank nichts falsch ist.
Wenn die Quelle noch verfügbar ist, kann ein neuer vollständiger Export die bessere Lösung sein.
Wie du einen Export korrekt erstellst, erklären wir unter Export database with phpMyAdmin.
SQL-Datei hat 0 Byte oder ist ungewöhnlich klein #
Eine leere oder unerwartet kleine Datei kann darauf hinweisen, dass bereits beim Export etwas nicht wie erwartet funktioniert hat.
Die Dateigröße allein ist zwar kein sicherer Beweis für Vollständigkeit, offensichtliche Abweichungen solltest du aber vor dem Import untersuchen.
Falsches Dateiformat #
Prüfe, ob es sich tatsächlich um einen geeigneten Datenbankexport handelt.
Eine Datei mit der Endung:
.sql
ist ein typisches Format für einen SQL-Export.
Eine beliebige CSV-, XML-, ZIP- oder Textdatei ist nicht automatisch ein vollständiger SQL-Datenbankexport.
Komprimierte Datei wird nicht akzeptiert #
Wenn phpMyAdmin eine komprimierte Datei nicht akzeptiert, prüfe zunächst, welche Kompressionsformate in der Importoberfläche tatsächlich unterstützt werden.
Ändere nicht einfach die Dateiendung.
Das Umbenennen von:
datenbank.zip
in
database.sql
wandelt den Inhalt nicht in eine SQL-Datei um.
Import ist erfolgreich, aber Website zeigt einen Datenbankfehler #
Ein erfolgreicher Import und eine funktionierende Datenbankverbindung sind zwei unterschiedliche Dinge.
Wenn die Tabellen vorhanden sind, die Website aber keine Verbindung herstellen kann, prüfe die Zugangsdaten der Anwendung.
Bei WordPress insbesondere:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOSTPrüfe außerdem, ob der Datenbankbenutzer der richtigen Datenbank zugewiesen wurde.
Import erfolgreich, aber Website zeigt falsche Inhalte #
Wenn die Website nach dem Import funktioniert, aber nicht die erwarteten Inhalte enthält, solltest du prüfen, ob tatsächlich der richtige Sicherungsstand importiert wurde.
Possible causes include, for example:
- ältere SQL-Sicherung verwendet
- falsche Quelldatenbank exportiert
- Anwendung greift auf eine andere Datenbank zu
- Import war unvollständig
Importiere nicht sofort eine weitere Sicherung darüber. Kläre zuerst, welche Datenbank die Anwendung aktuell verwendet.
Import erfolgreich, aber Website verwendet weiterhin die alte Datenbank #
Das Erstellen und Importieren einer neuen Datenbank ändert nicht automatisch die Konfiguration deiner Website.
Die Anwendung verwendet weiterhin die Datenbankzugänge, die in ihrer Konfiguration hinterlegt sind.
Bei WordPress ist dies normalerweise:
wp-config.php
Fehler nach Änderung des Datenbankpassworts #
Wenn du während der Migration das Passwort des Datenbankbenutzers geändert hast, muss das neue Passwort auch in der Anwendung hinterlegt werden.
Eine Änderung in cPanel aktualisiert die Konfigurationsdateien deiner Website nicht automatisch.
Import erfolgreich, aber Tabellen fehlen #
Wenn nur ein Teil der erwarteten Tabellen vorhanden ist, prüfe zuerst die ursprüngliche SQL-Datei und die Importmeldung.
Mögliche Ursachen sind:
- unvollständiger Export
- abgebrochener Import
- nur ausgewählte Tabellen wurden exportiert
- Fehler während des Imports
Gehe nicht allein anhand einer erwarteten Tabellenanzahl davon aus, dass Tabellen fehlen. Anwendungen und Plugins können unterschiedlich viele Tabellen verwenden.
WordPress-Präfix nicht mit fehlenden Tabellen verwechseln #
Bei WordPress müssen Tabellen nicht mit:
wp_
beginnen.
Eine Installation kann beispielsweise ein Präfix wie:
abc_
use.
Prüfe deshalb die tatsächlichen Tabellennamen, bevor du annimmst, dass keine WordPress-Daten vorhanden sind.
Import überschreibt nicht automatisch alle alten Daten #
Ob vorhandene Tabellen beziehungsweise Datensätze ersetzt werden, hängt von den SQL-Anweisungen in der Importdatei ab.
Eine SQL-Datei kann beispielsweise:
- neue Tabellen erstellen
- Datensätze einfügen
- vorhandene Tabellen löschen und neu erstellen
- bestehende Daten verändern
Deshalb solltest du niemals davon ausgehen, dass jeder Import automatisch einen identischen Datenbankzustand erzeugt.
DROP TABLE in der SQL-Datei #
Enthält die Sicherung Anweisungen wie:
DROP TABLE ...können vorhandene Tabellen vor ihrer Neuerstellung entfernt werden.
Das kann bei einer gezielten Wiederherstellung sinnvoll sein, ist bei einer falschen Zieldatenbank jedoch besonders gefährlich.
Attention: Die Auswahl der richtigen Zieldatenbank ist bei einer SQL-Datei mit
DROP-Anweisungen besonders wichtig.
INSERT-Fehler nach einem abgebrochenen Import #
Wenn ein erster Import bereits Datensätze eingefügt hat, kann ein zweiter Versuch an denselben Datensätzen scheitern.
Das ist ein weiterer Grund, warum ein fehlgeschlagener Import nicht einfach wiederholt werden sollte.
Fehler wegen Fremdschlüsseln #
Bestimmte Anwendungen verwenden Beziehungen zwischen Tabellen, die durch sogenannte Fremdschlüssel abgesichert werden können.
Wenn ein Import gegen solche Beziehungen verstößt, kann der Datenbankserver eine entsprechende Fehlermeldung ausgeben.
Deaktiviere solche Prüfungen nicht auf Verdacht. Sie können die Konsistenz zusammengehöriger Daten schützen.
SQL_MODE- oder Versionsunterschiede #
Eine SQL-Datei aus einer anderen Datenbankserver-Version kann Anweisungen oder Daten enthalten, die vom Zielsystem strenger oder anders verarbeitet werden.
Wenn die Fehlermeldung auf einen konkreten SQL-Modus, Datentyp oder ungültigen Wert hinweist, sollte die Kompatibilität zwischen Quell- und Zielumgebung geprüft werden.
Serverweite Datenbankeinstellungen sollten nicht allein zur Umgehung eines einzelnen Importfehlers verändert werden.
Import aus sehr alter Hosting-Umgebung #
Bei Datenbanken aus deutlich älteren Serverumgebungen können Kompatibilitätsunterschiede häufiger auftreten.
This may include, for example:
- alte Zeichensätze
- abweichende Kollationen
- veraltete SQL-Syntax
- unterschiedliche Datenbankserver-Versionen
- alte Anwendungsstrukturen
In solchen Fällen ist die konkrete Fehlermeldung entscheidend für die weitere Vorgehensweise.
Import aus neuerer Datenbankserver-Version #
Auch der umgekehrte Fall kann problematisch sein: Eine SQL-Datei wurde auf einem System erzeugt, das Funktionen oder Kollationen unterstützt, die auf dem Zielsystem nicht vorhanden sind.
Prüfe deshalb bei Kompatibilitätsfehlern sowohl die Quell- als auch die Zielumgebung.
Nicht jede Fehlermeldung ist ein phpMyAdmin-Fehler #
phpMyAdmin ist die Oberfläche, über die du den Import startest. Viele angezeigte Fehlermeldungen stammen jedoch vom darunterliegenden Datenbankserver.
Ein Fehler während eines Imports bedeutet deshalb nicht automatisch, dass phpMyAdmin selbst defekt ist.
PHP-Limits und Datenbankfehler unterscheiden #
Ein Upload- oder Laufzeitlimit betrifft den technischen Importvorgang über die Weboberfläche.
Ein Fehler wie:
#1050 - Table already exists
betrifft dagegen die Verarbeitung der SQL-Anweisungen innerhalb der Datenbank.
Eine Erhöhung eines PHP-Limits löst einen solchen SQL-Fehler nicht.
PHP-Einstellungen nicht für jeden Importfehler ändern #
Wenn tatsächlich ein Upload- oder Laufzeitlimit relevant ist, können PHP-Einstellungen eine Rolle spielen.
Wie PHP-Einstellungen in cPanel verwaltet werden, behandeln wir später unter Change PHP settings in cPanel.
Prüfe aber zuerst die konkrete Fehlermeldung. SQL-Syntax-, Tabellen- oder Berechtigungsfehler werden durch größere PHP-Limits nicht behoben.
Wann ein neuer sauberer Import sinnvoll sein kann #
Ein neuer Import in eine saubere Datenbank kann insbesondere dann sinnvoll sein, wenn:
- die Zieldatenbank ausschließlich für diese neue Migration erstellt wurde
- keine produktiven Daten darin vorhanden sind
- der vorherige Import nachweislich nur teilweise ausgeführt wurde
- die Ursache des Abbruchs behoben wurde
- eine vollständige Ausgangssicherung vorhanden ist
Bevor du Daten entfernst, müssen diese Voraussetzungen eindeutig geklärt sein.
Wann du die bestehende Datenbank nicht leeren solltest #
Leere beziehungsweise lösche eine Datenbank nicht, wenn:
- eine aktive Website sie verwendet
- du nicht sicher weißt, wem sie gehört
- neue produktive Daten darin entstanden sein könnten
- keine aktuelle Sicherung vorhanden ist
- du den bisherigen Importzustand noch nicht analysiert hast
Basic rule: Unklarer Datenbankzustand bedeutet zuerst analysieren – nicht löschen.
Systematische Fehlersuche bei einem fehlgeschlagenen Import #
- Import nicht sofort erneut starten.
- Vollständige Fehlermeldung sichern.
- Richtige Zieldatenbank kontrollieren.
- Prüfen, ob bereits Tabellen importiert wurden.
- Größe und Format der SQL-Datei kontrollieren.
- Unterscheiden, ob ein Upload-, Laufzeit-, SQL-, Berechtigungs- oder Kompatibilitätsproblem vorliegt.
- Bei SQL-Fehlern Fehlernummer und betroffene Anweisung prüfen.
- Bei einer teilweise importierten Datenbank deren Zustand dokumentieren.
- Ursache beheben.
- Erst danach entscheiden, ob der Import fortgesetzt oder sauber neu begonnen wird.
Schnelle Einordnung typischer Fehler #
| Problem | Wahrscheinlicher Bereich |
|---|---|
| Datei lässt sich wegen Größe nicht hochladen | Upload-Limit |
| Import startet und bricht später ab | Laufzeit, Größe oder SQL-Fehler |
#1044 | Datenbankberechtigung / nicht erlaubte Datenbankoperation |
#1045 | Authentifizierung / Zugriff |
#1050 | Tabelle existiert bereits |
#1062 | Doppelter eindeutiger Wert |
#1064 | SQL-Syntax |
Unknown collation | Kompatibilität / Kollation |
| Falsche Umlaute oder Sonderzeichen | Zeichensatz / Export-Import-Kette |
| Website meldet Datenbankverbindungsfehler | Zugangsdaten / Benutzerzuweisung |
| Tabellen fehlen nach Import | Teilimport oder unvollständiger Export |
Vor einer Supportanfrage nichts „reparieren“ #
Wenn du die Ursache nicht eindeutig erkennst, ist es häufig besser, den aktuellen Zustand unverändert zu lassen.
Durch zusätzliche Lösch-, Import- oder SQL-Versuche können wichtige Hinweise auf die ursprüngliche Ursache verloren gehen.
Notiere beziehungsweise sichere deshalb zuerst die Fehlermeldung und den aktuellen Datenbankzustand.
Welche Informationen benötigt der Support? #
Für eine gezielte Analyse sind insbesondere folgende Angaben hilfreich:
- affected domain or application
- vollständiger Name der Zieldatenbank
- Größe der SQL-Datei
- Dateiformat beziehungsweise Komprimierung
- ob die Datenbank vor dem Import leer war
- ob bereits Tabellen importiert wurden
- genaue Fehlernummer
- vollständiger Fehlertext
- betroffene Tabelle, sofern angezeigt
- ob es sich um Migration oder Wiederherstellung handelt
- aus welcher Hosting- beziehungsweise Datenbankumgebung die Sicherung stammt, sofern bekannt
A screenshot of the error message can also be helpful.
Safety: Übermittle keine Datenbankpasswörter und stelle SQL-Sicherungen mit sensiblen Daten nicht öffentlich zum Download bereit.
Summary #
Wenn ein phpMyAdmin-Import fehlschlägt, solltest du ihn nicht sofort erneut starten. Prüfe zuerst die vollständige Fehlermeldung und kontrolliere, ob die Zieldatenbank bereits teilweise importierte Tabellen oder Datensätze enthält.
Probleme vor dem eigentlichen Import deuten häufig auf Dateigröße, Upload oder Format hin. Bricht ein bereits laufender Import ab, können Laufzeitgrenzen, SQL-Fehler oder Kompatibilitätsprobleme eine Rolle spielen.
Fehler wie #1044, #1045, #1050, #1062 or #1064 weisen auf unterschiedliche Ursachen hin und sollten entsprechend der konkreten Meldung behandelt werden. Eine Erhöhung von PHP-Limits ist deshalb keine allgemeine Lösung für Datenbankfehler.
Besondere Vorsicht ist bei teilweise importierten Datenbanken erforderlich. Lösche bestehende Tabellen oder Datenbanken nur dann, wenn eindeutig feststeht, dass keine benötigten produktiven Daten betroffen sind und eine geeignete Sicherung vorhanden ist.
Die wichtigste Regel bei einem fehlgeschlagenen Import lautet deshalb: Fehlermeldung sichern, Datenbankzustand prüfen, Ursache bestimmen – und erst danach den nächsten Importversuch starten.
