![]() ![]() ![]() |
Online Suche im Handbuch | ![]() |
Im Moment sind ja kaum Daten in der Tabelle enthalten. Der Grund, warum das Kapitel Exportieren .... vorgezogen wird, ist derjenige, daß wir erst einmal schauen möchten, in welchem Datenformat die Daten abgelegt werden. Es ist logisch, daß MySQL diese Daten dann auch wieder importieren kann. Schauen wir uns etwas im Kapitel Sprachreferenz MySQL um. Logischerweise muß man zuerst Daten auswählen, die dann exportiert werden können, daher muß der Befehl also im Kapitel SELECT zu finden sein....genau SELECT FROM table into outfile "name"; Wir probieren es zunächst aus gutem Grund mit dem LINUX Client auf dem MySQL Server:
user01@tunix:~/SGML > mysql -h 10.0.0.5 -u testuser -ptestpasswort test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 10 to server version: 3.21.33b
Type 'help' for help.
mysql> select * from testtabelle into outfile "datenexport.txt";
Query OK, 2 rows affected (0.03 sec)
mysql> quit
Wir merken uns, daß alle Dateinamen, Strings u.s.w. stets in
Anführungszeichen stehen müssen.
Schön, wo sind die Daten nun hin ? Wie sehen Sie aus ? Wir können feststellen, daß die Daten nicht, wie zunächst vermutet, im Verzeichnis des MySQL Client unter LINUX sind. MySQL hat beim Kompilieren immer ein Verzeichnis angegeben bekommen, in welchem standardmäßig immer alle Datenbanken versammelt auf der Festplatte gespeichert sind. Dies ist das Verzeichnis /var/mysql. Hier finden sich alle unsere Datenbanken und Tabellen wieder:
user01@tunix:/var/mysql > ls -la
total 9
drwxr-xr-x 4 root root 1024 Aug 27 07:10 .
drwxr-xr-x 24 root root 1024 Mar 12 17:49 ..
drwxr-xr-x 2 root root 1024 Aug 19 10:26 mysql
drwxr-xr-x 2 root root 1024 Aug 27 09:18 test
-rw-r--r-- 1 root root 794 Aug 27 07:10 tunix.err
-rw-r--r-- 1 root root 2418 Aug 27 07:10 tunix.log
-rw-r--r-- 1 root root 3 Aug 27 07:10 tunix.pid
user01@tunix:/var/mysql >
Schauen wir uns nun im Verzeichnis test um:
user01@tunix:/var/mysql > cd test
user01@tunix:/var/mysql/test > ls -la
total 14
drwxr-xr-x 2 root root 1024 Aug 27 09:18 .
drwxr-xr-x 4 root root 1024 Aug 27 07:10 ..
-rw-rw-rw- 1 root root 18 Aug 27 09:18 datenexport.txt
-rw-rw---- 1 root root 52 Aug 27 07:41 testtabelle.ISD
-rw-rw---- 1 root root 1024 Aug 27 07:41 testtabelle.ISM
-rw-rw---- 1 root root 8590 Aug 27 07:12 testtabelle.frm
user01@tunix:/var/mysql/test >
Aha, logischerweise speichert MySQL die Exportdateien ebenfalls in dem
Verzeichnis ab, in dem sich die MySQL Datenbank befindet.....Schauen wir uns
die Datenbank einmal an.....
user01@tunix:/var/mysql/test > more datenexport.txt
5 test
5 testwert
user01@tunix:/var/mysql/test >
Fein ! Wir fügen also einfach mit dem Editor joe ein paar Daten
hinzu. An dieser Stelle sollten wir vielleicht die wichtigsten Kommandos von
joe erklären:
5 test
5 testwert
34567 kannix und istnix weissnix habenix
Beim Speichern erscheint vielleicht eine Fehlermeldung (could not make
backup file, save anyway ?). Das ist so korrekt, wenn Sie nur als User
eingeloggt sind. Die Rechte an der Datei selber haben Sie, jedoch Sie haben
kein Recht, Dateien mit Ihrem Useraccount anzulegen. Es funktioniert aber
trotzdem. Diese veränderten Daten sollten wir probeweise einmal einlesen.
Hierzu verwenden wir das Statement aus unserer MySQL Sprachreferenz load
data infile..., siehe hierzu auch Kapitel
LOAD DATA INFILE.
user01@tunix:~/SGML > mysql -h 10.0.0.5 -u testuser -ptestpasswort test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 11 to server version: 3.21.33b
Type 'help' for help.
mysql> load data infile "datenexport.txt" into table testtabelle;
Query OK, 3 rows affected (0.13 sec)
Records: 3 Deleted: 0 Skipped: 0 Warnings: 1
mysql>
Wir überprüfen einmal....
mysql> select * from testtabelle;
+---------+----------------------+
| spalte1 | spalte2 |
+---------+----------------------+
| 5 | test |
| 5 | testwert |
| 5 | test |
| 5 | testwert |
| 34567 | kannix und istnix we |
+---------+----------------------+
5 rows in set (0.00 sec)
mysql>
Tja, irgendwie hat es ja funktioniert, leider haben wir nun ein Problem, was
wahrscheinlich viele teilen. Daher haben wir es hier auch provoziert.....
Es wurden Daten beim Import abgeschnitten. Dies ist ein recht häufiges Problem. Man stellt fast immer erst später fest, daß es den einen oder anderen Datensatz gibt, der doch länger ist, als man vorher bei der Definition der Tabelle gedacht hat. Zur Erinnerung: Wir hatten die Länge des Feldes spalte2 mit char(20) angegeben.....zuwenig !
Also sollten wir unsere MySQL Sprachreferenz einmal wieder bemühen.....ALTER ist im Abschnitt ALTER zu finden. ALTER table MODIFY sollte passen ! Wir werden nach der Veränderung der Spalte die Daten nochmals importieren und den Tabelleninhalt schließlich ausgeben:
mysql> alter TABLE testtabelle modify spalte2 char(30);
ERROR 1064: parse error near 'modify spalte2 char(30)' at line 1
mysql>
mysql> alter TABLE testtabelle change spalte2 spalte2 char(40);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> load data infile "datenexport.txt" into table testtabelle;
Query OK, 3 rows affected (0.01 sec)
Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
mysql> select * from testtabelle;
+---------+------------------------------------+
| spalte1 | spalte2 |
+---------+------------------------------------+
| 5 | test |
| 5 | testwert |
| 34567 | kannix und istnix we |
| 5 | test |
| 5 | testwert |
| 34567 | kannix und istnix weissnix habenix |
+---------+------------------------------------+
6 rows in set (0.00 sec)
mysql>
Aus irgendeinem Grund hat MySQL die Syntax mit MODIFY nicht akzeptiert.
Schauen wir noch einmal genau in die Sprachreferenz von MySQL.
Offensichtlich ist diese Syntax erst seit der Version 3.22.16a möglich, da
hier ein Tribut an ORACLE gemacht wurde. MODIFY ist kein ANSI SQL 92
Ausdruck, jedoch häufig verwandt, da ORACLE quasi als Standard angesehen
werden kann. MySQL unterstützt viele ORACLE Klauseln, LOAD DATA INFILE ...
ist z.B. eine solche, die nur ORACLE und MySQL beherrschen. Damit man
Datensätze beim Einlesen überschreiben kann, hat das Statement LOAD DATA
LOCAL INFILE INTO tabelle .... noch eine Option REPLACE, die die
aktuelleren Datensätze aus der Importdatei in der Tabelle ersetzt. Das funktioniert nur in Verbindung mit
UNIQUE Keys.. .Offensichtlich hat es mit dem Ausdruck CHANGE funktioniert, allerdings
sollten Sie beachten, daß der Spaltenname doppelt angegeben werden muß:
mysql> alter TABLE testtabelle change spalte2 spalte2 char(40);
Danach haben wir die Daten noch einmal eingelesen. Bitte beachten Sie, daß SQL hier Daten hinzugefügt hat, ohne zu bemerken, daß diese bereits in der Datenbank enthalten sind. Das ist ein häufiger Fehler, aber kein Problem. Dafür gibt es die DELETE Syntax, mit der wir die Tabelle vor dem Einlesen der Daten von der Festplatte löschen können:
delete from testtabelle; load data infile "datenexport.txt" into table
testtabelle; select * from testtabelle;
Query OK, 0 rows affected (0.00 sec)
-> testtabelle; select * from testtabelle;
Query OK, 3 rows affected (0.00 sec)
Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
+---------+------------------------------------+
| spalte1 | spalte2 |
+---------+------------------------------------+
| 5 | test |
| 5 | testwert |
| 34567 | kannix und istnix weissnix habenix |
+---------+------------------------------------+
3 rows in set (0.00 sec)
mysql>
Wie man nun sehen kann, darf man viele Statements in eine Zeile schreiben,
solange man jedes Statement mit einem Semikolon beendet und somit von
anderen Statements abtrennt. Das Ergebnis ist wie gewünscht.
![]() ![]() ![]() |
Online Suche im Handbuch | ![]() |