Problem bei import einer mysqldump -Datei!

Hallo!

Ich muss von einem alten Windows Server mit MySQL 3.23.52 auf einen neuen
Server umziehen. Auf diesem Server läuft aber nur die Version 4.1.22 (oder
auf Wunsch die Version 5.x.x).

Ich habe nun mit 'mysqldump' eine SQL-Datei der alten Datenbank erstellt,
und wollte Sie nun auf dem neuen Server zurückspielen. Nach einer ganzen
Weile bekomme ich folgende Fehlermeldung:

***
ERROR 1064 (42000) at line 367993: 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 'key (wordkey)
> TYPE=MyISAM' at line 7
***

Leider bin ich weder Programmierer (ein bisschen kann ich schon), noch der
Ersteller der Webanwendung oder der Datenbank, darum habe ich nicht die
geringste Idee...

Kann mir bitte jemand einen Tipp geben, woran es liegen könnte? Ist evtl.
die Datenbank defekt? Wie prüfe ich das? Kann ich nicht direkt von einem
3er auf einen 4.1er updaten (vielleicht muss ich zuvor auf einen 4.0er und
dann weiter)?

Ich hätte es auch über die 'MySQL GUI Tools' versucht, aber mit denen kann
ich nicht auf einen 3er Server zugreifen!

Danke,
Christian.

Re: Problem bei import einer mysqldump -Datei!

Christian-Josef Schrattenthaler schrieb:
> Hallo!
>
> Ich muss von einem alten Windows Server mit MySQL 3.23.52 auf einen neuen
> Server umziehen. Auf diesem Server läuft aber nur die Version 4.1.22 (oder
> auf Wunsch die Version 5.x.x).

Wenn die Option besteht, lieber 5.x.x.
Der Firmensupport für 4.x.x ist ausgelaufen, d.h. es gibt von mysql AB
keine Sicherheitsupdates mehr, keine Fehlerkorrekturen, kein gar nix.
Bei einer guten Distribution kriegt man diesen Support dann von der
Distribution, aber die werden in absehbarer Zeit (ein bis zwei Jahre,
allerhöchstens) ebenfalls den Support einstellen.

> Ich habe nun mit 'mysqldump' eine SQL-Datei der alten Datenbank erstellt,
> und wollte Sie nun auf dem neuen Server zurückspielen. Nach einer ganzen
> Weile bekomme ich folgende Fehlermeldung:
>
> ***
> ERROR 1064 (42000) at line 367993: 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 'key (wordkey)
>> TYPE=MyISAM' at line 7
> ***

Na, immerhin geht's voran :-)

Wir müssten die SQL-Anweisung auf Zeile 367993 sehen.

> Ist evtl. die Datenbank defekt?

Das ist möglich, aber wahrscheinlich nicht das Problem.

> Wie prüfe ich das?

Es gibt einen CHECK-Befehl, glaube ich.

Zuverlässiger wäre es wahrscheinlich, das komplette mysql vom Server zu
schmeißen und neu zu installieren. Ich vermute mal, dass es auch
einfacher wäre.
Vorgehen:
1. Nachschauen, in welchem Verzeichnis mysql die Datenbankdateien
ablegt. (phpmyadmin und "Variablen" anzeigen lassen, da ist diese Angabe
auch dabei - auf einem Unix-System würde ich /etc/my.cnf ansehen, aber
erinnere mich dumpf, dass Du immer mal wieder Windows-Programme erwähnt
hast)
2. mysql deinstallieren.
3. Das Datenverzeichnis löschen.
4. mysql 5.x.x installieren.
5. Den Dump einspielen.

Wie gesagt, ich vermute, dass das oben beschriebene Problem davon nicht
weggeht, aber wenn Du die gleichen Datenbankdateien schon abwechselnd
mit mysql 4 und mysql 5 traktiert hast, würde ich das auf jeden Fall
machen - mysql *sollte* mit solchen Abläufen klarkommen, aber wirklich
gründliche getestet werden sie natürlich nicht und man hat dann schnell
einen subtilen Bug ausgelöst, der in der Datenbank einen leichten
Dachschaden hinterlassen hat.

> Kann ich nicht direkt von einem
> 3er auf einen 4.1er updaten (vielleicht muss ich zuvor auf einen 4.0er und
> dann weiter)?

Geht auch irgendwie, aber damit kenn ich mich nicht aus.

Grüße
Jo

Re: Problem bei import einer mysqldump -Datei!

Hallo!

Ich fange jetzt nochmals ganz neu an:

Am alten Server habe ich noch nie etwas gemacht, der ist also komplett
unberührt, und das muss auch so bleiben.

Ich persönlich würde auch lieber die 5er anstatt die 4er am neuen Server
einsetzen, aber jetzt muss ich mich erst mal langsam herantasten.

Auf meinem privaten Computer habe ich mit jetzt die letzte 3er installiert,
die ich finden konnten, und dann den 'Data' Ordner vom alten Server
kopiert. Nun kann ich ein bisschen experimentieren, ohne das System zu
gefährden.

Ich habe eine 'row' mit einem falschen auto-increment gelöscht, die war eh
leer. Und dann habe ich über HeidiSQL die Datenbank repariert und
optimiert. Ein Anschließender Check ergab dann 0 Fehler (alles Ok!). Soweit
war ich noch nie ;-)

Dann habe ich versucht per HeidiSQL einen Datenaustausch zu machen, aber
die SQL-Datei ist natürlich auch defekt, und der Fehler wird nicht genau
beschrieben, also habe cih es wieder mit mysqldum versucht.

Nun kommt der Fehler:

***
ERROR 1064 at line 367992: You habe an error in your SQL syntax near 'key
(wordkey) > TYPE=MYISAM at line 7
***

Hier der Inhalt der Datei von Zeile 367986 bis Zeile 368006:

***
INSERT INTO icsp_std VALUES
(477,2,'2003-03-07',6,6,1,'ICSP',42,0,'Diverses',0);

--
-- Table structure for table `language_translations`
--

CREATE TABLE language_translations (
id int(11) NOT NULL auto_increment,
wordkey varchar(100) NOT NULL default '',
d varchar(100) NOT NULL default '',
gb varchar(100) NOT NULL default '',
PRIMARY KEY (id),
UNIQUE KEY key (wordkey)
) TYPE=MyISAM;

--
-- Dumping data for table `language_translations`
--


INSERT INTO language_translations VALUES
(1,'standort','Standort','Location');
***

Ich kann es also nicht mal mehr in einen 3er selbst zurückkopieren...

Bin echt schon am Verzweifeln...

Danke,
Christian.

Re: Problem bei import einer mysqldump -Datei!

Hi!

Thus spake Christian-Josef Schrattenthaler on 04/09/2007 03:29 PM:
> UNIQUE KEY key (wordkey)


Da ist dein Problem: "key" ist ein reserviertes Wort und darf daher
nicht als Name für den Key selbst herhalten. Du könntest den Namen
einfach ändern, mit ein wenig Glück wird das die Anwendung oben
drüben nicht wirklich stören.

Bis denne,

Phil

Re: Problem bei import einer mysqldump -Datei!

Also sprach Philipp Taprogge

> Da ist dein Problem: "key" ist ein reserviertes Wort und darf daher
> nicht als Name für den Key selbst herhalten. Du könntest den Namen
> einfach ändern, mit ein wenig Glück wird das die Anwendung oben
> drüben nicht wirklich stören.

Reicht es da nicht aus, `key` in backticks zu setzen?

--
Too many ingredients in the soup, no room for a spoon.
http://news.motzarella.org

Re: Problem bei import einer mysqldump -Datei!

Philipp Taprogge wrote:
> Hi!
>
> Thus spake Christian-Josef Schrattenthaler on 04/09/2007 03:29 PM:
>> UNIQUE KEY key (wordkey)
>
>
> Da ist dein Problem: "key" ist ein reserviertes Wort und darf daher
> nicht als Name für den Key selbst herhalten. Du könntest den Namen
> einfach ändern, mit ein wenig Glück wird das die Anwendung oben
> drüben nicht wirklich stören.

Oder --allow-keywords beim mysqldump verwenden...

Stefan

Re: Problem bei import einer mysqldump -Datei!

Philipp Taprogge schrieb:
>
> Thus spake Christian-Josef Schrattenthaler on 04/09/2007 03:29 PM:
>> UNIQUE KEY key (wordkey)
>
> Da ist dein Problem: "key" ist ein reserviertes Wort und darf daher
> nicht als Name für den Key selbst herhalten. Du könntest den Namen
> einfach ändern, mit ein wenig Glück wird das die Anwendung oben
> drüben nicht wirklich stören.

Ich glaub nicht, dass man sich nach zwei Tagen Frust noch aufs Glück
verlassen möchte ;-)


Backquotes (backticks, `) sind wahrscheinlich die beste Lösung:

UNIQUE KEY `key` (wordkey)

Noch besser: Den mysqldump gleich mit einer Option laufen lassen, die
die Backticks automatisch einsetzt.
Ich weiß leider nicht, welche das ist und ob es sie schon bei 3.x gibt.
mysqldump --help sollte diese Frage allerdings beantworten :-)

Grüße
Jo

Re: Problem bei import einer mysqldump -Datei!

Joachim Durchholz wrote:
> Philipp Taprogge schrieb:
>> Thus spake Christian-Josef Schrattenthaler on 04/09/2007 03:29 PM:
>>> UNIQUE KEY key (wordkey)
>>
>> Da ist dein Problem: "key" ist ein reserviertes Wort und darf daher
>> nicht als Name für den Key selbst herhalten. Du könntest den Namen
>> einfach ändern, mit ein wenig Glück wird das die Anwendung oben
>> drüben nicht wirklich stören.
>
> Ich glaub nicht, dass man sich nach zwei Tagen Frust noch aufs Glück
> verlassen möchte ;-)
>
> Backquotes (backticks, `) sind wahrscheinlich die beste Lösung:
>
> UNIQUE KEY `key` (wordkey)
>
> Noch besser: Den mysqldump gleich mit einer Option laufen lassen, die
> die Backticks automatisch einsetzt.

Was heißt hier "noch besser"? Es funktioniert überhaupt nur, wenn das
Programm, das den SQL-Dump schreibt, die Backticks richtig setzt.
Typischerweise setzt das dann gleich alle Identifier in Backticks.

> Ich weiß leider nicht, welche das ist und ob es sie schon bei 3.x gibt.
> mysqldump --help sollte diese Frage allerdings beantworten :-)

Wenn man die Daten in ein 5.0 importieren will, dann ist es *höchst*
empfehlenswert, auch das mysqldump von 5.0 für den Export zu bemühen.
Ansonsten darf man sich gleich um den nächsten Syntaxfehler wegen
"TYPE=MyISAM" (neu: "ENGINE=MyISAM") kümmern und die zerbrochenen
Umlaute reparieren.


@ Christian-Josef:

So wird das nix. Du bist offensichtlich blutiger Anfänger. Ohne ein
Minimum an Studium der Dokumentation wirst du nicht weit kommen. Und
hier ist nicht der richtige Platz, dir einen komplexen Vorgang wie ein
Upgrade von 3.23 auf 5.0 oder das Tuning eines verkorksten Datenmodells
so detailliert zu erläutern, daß du das hinbekommst ohne dich dreimal
am Tag auf die Nase zu legen. Also such dir jemand, der sich damit
auskennt (nein, nicht mich). Oder lerne es selber. Allerdings könnte
das mit dem Lernen etwas aufwendig werden. Für die Upgrade-Problematik
müßtest du z.B. das hier lesen und verstehen (!)

http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.h tml
http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-4-0.ht ml
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.ht ml



XL

Re: Problem bei import einer mysqldump -Datei!

Axel Schwenke schrieb:
> Wenn man die Daten in ein 5.0 importieren will, dann ist es *höchst*
> empfehlenswert, auch das mysqldump von 5.0 für den Export zu bemühen.

Da tauscht er einen Satz Probleme gegen einen anderen aus.
Mir kommt es jedenfalls nicht gerade einfach vor, ein 5er mysqldump und
eine 3er Datenbank friedlich koexistieren zu lassen. Im dümmsten Fall
erwischt er dann trotzdem den ebenfalls installierten 3er mysqldump...

> Ansonsten darf man sich gleich um den nächsten Syntaxfehler wegen
> "TYPE=MyISAM" (neu: "ENGINE=MyISAM") kümmern und die zerbrochenen
> Umlaute reparieren.

TYPE= wird immer noch unterstützt (Ausnahmen: Releases 5.1.7 und alle ab
5.2.0).

Die Umlaute kriegt man im Dump mit einem Texteditor per Suchen&Ersetzen
wieder hin.

> @ Christian-Josef:
>
> So wird das nix. Du bist offensichtlich blutiger Anfänger.

@Christian-Josef: lass Dich nicht ins Bockshorn jagen.
Wir waren alle mal blutige Anfänger.

> Für die Upgrade-Problematik
> müßtest du z.B. das hier lesen und verstehen (!)
>
> http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.h tml
> http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-4-0.ht ml
> http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.ht ml

Das wären die Alternativen, wenn man die Datenbanken direkt konvertieren
möchte, ohne den Zwischenschritt über mysqldump zu gehen.
Kommt mir allerdings ziemlich aufwändig vor.

Grüße
Jo

Re: Problem bei import einer mysqldump -Datei!

Hallo!

Vielen Dank für Eure Tipps. Mit mysqldump komme ich mittlerweile gut klar.
Ich habe jetzt eine 3.23.58, eine 4.0.27, eine 4.1.22 und eine 5.0.37
Version beim Laufen (abwechselnd, logischer Weise).

Die Daten habe ich mir tatsächlich mit den jeweiligen mysqldump-Versionen
von der 3er in die jeweilige neue Version geholt. Nur die 3er und die 4.0er
hatten das Problem mit dem `key`, welches per Texteditor schnell behoben
ist.

Weiters habe ich jetzt ein nettes GUI-Tool (www.heidisql.com) gefunden,
welches mir auch ein bisschen hilft, und eine kleine Testanwendung mit
meinen bescheidenen Programmierkenntnissen (Java) habe ich auch zum Laufen
gebracht. Damit kann ich die 'alten' SELECT-Anweisungen testen.

Mit der 3er und der 4.0er scheint unsere 'alte' (VBScript) Webanwendung
keine Probleme zu haben, aber mit der 4.1er und der 5.0er tauchen ganz
komische Probleme (zB die hohe CPU-Auslastung) auf.

Wichtig ist jetzt nur mal, dass ich den Serverumzug (vermutlich mit der
4.0er) hinbekomme. Für die Umstellung auf die 4.1er und dann die 5.0er
haben wir dann ein bisschen mehr Zeit.

Vielleicht fällt dem Einen oder Anderen von Euch noch was ein, was die
Kompatibilitätsprobleme verursachen könnte!?

Danke,
Christian.

Re: Problem bei import einer mysqldump -Datei!

Christian-Josef Schrattenthaler schrieb:
> Mit der 3er und der 4.0er scheint unsere 'alte' (VBScript) Webanwendung
> keine Probleme zu haben, aber mit der 4.1er und der 5.0er tauchen ganz
> komische Probleme (zB die hohe CPU-Auslastung) auf.

Sollte eigentlich nicht sein.
Klingt nach fehlenden Indexen.

> Vielleicht fällt dem Einen oder Anderen von Euch noch was ein, was die
> Kompatibilitätsprobleme verursachen könnte!?

Da gibt's viel zuviele Möglichkeiten.

Am besten ist es, Du findest raus, welche Queries zu lange benötigen.
Dann haben wir hier auch einen Ansatzpunkt.

Grüße
Jo

Re: Teil einer mySQL-Abfrage an PHP-Variable hängen? Geht das?

odermann@googlemail.com schrieb:
> Axel Schwenke schrieb:
>> Wenn man die Daten in ein 5.0 importieren will, dann ist es *höchst*
>> empfehlenswert, auch das mysqldump von 5.0 für den Export zu bemühen.
>
> Da tauscht er einen Satz Probleme gegen einen anderen aus.
> Mir kommt es jedenfalls nicht gerade einfach vor, ein 5er mysqldump und
> eine 3er Datenbank friedlich koexistieren zu lassen. Im dümmsten Fall
> erwischt er dann trotzdem den ebenfalls installierten 3er mysqldump...

Also ganz ehrlich: Wer das nicht hinbekommt, sollte besser die Finger
von Serversoftware lassen und Excel für seine Tabellen benutzen. Ein
Binary (nebst evtl. vorhandener Libraries) von einem Rechner auf einen
anderen zu kopieren und dort auszuführen, ist nun wirklich keine
Aufgabe, für die man sein Hirn übermäßig strapazieren muß.

Grüße,
Dominik

Re: Teil einer mySQL-Abfrage an PHP-Variable hängen? Geht das?

Dominik Echterbruch schrieb:
> Ein
> Binary (nebst evtl. vorhandener Libraries) von einem Rechner auf einen
> anderen zu kopieren und dort auszuführen, ist nun wirklich keine
> Aufgabe, für die man sein Hirn übermäßig strapazieren muß.

Seufz.
Warum nehmen die Leute immer an, dass das, was für sie piepeinfach ist,
das für jeden anderen auch sein muss...

Der Mann arbeitet schließlich mit Windows, wie man zwischen den Zeilen
lesen konnte.
Davon abgesehen würde es selbst unter Linux erhöhte Aufmerksamkeit
erfordern.
Und schlussendlich hat er selbst gesagt, er ist halt die arme Sau, an
der der Job hängengeblieben ist, er ist nur der dumme Admin, nicht der
Softwareentwickler. Wie's in so einer Firma halt ist.

Also etwas Zurückhaltung beim Fingerzeigen... danke...

Grüße
Jo

Re: Teil einer mySQL-Abfrage an PHP-Variable

Joachim Durchholz wrote:

> Der Mann arbeitet schließlich mit Windows, wie man zwischen den Zeilen
> lesen konnte.
> Davon abgesehen würde es selbst unter Linux erhöhte Aufmerksamkeit
> erfordern.
> Und schlussendlich hat er selbst gesagt, er ist halt die arme Sau, an
> der der Job hängengeblieben ist, er ist nur der dumme Admin, nicht der
> Softwareentwickler. Wie's in so einer Firma halt ist.
Ja und? Eine Transferierung der Daten eines mysql-Systems zum anderen ist doch
nur nur reine admin-Tätigkeit ;-)

S.

Re: Teil einer mySQL-Abfrage an PHP-Variable hängen? Geht das?

Joachim Durchholz schrieb:
>> Ein Binary (nebst evtl. vorhandener Libraries) von einem Rechner auf
>> einen anderen zu kopieren und dort auszuführen, ist nun wirklich keine
>> Aufgabe, für die man sein Hirn übermäßig strapazieren muß.
>
> Seufz.
> Warum nehmen die Leute immer an, dass das, was für sie piepeinfach ist,
> das für jeden anderen auch sein muss...

Zum Beispiel, weil er auf dem falschen Arbeitsplatz sitzt, wenn er
solche Dinge nicht beherrscht.

> Der Mann arbeitet schließlich mit Windows, wie man zwischen den Zeilen
> lesen konnte.

Selbst die dürften schon mal was von der DOS-Box oder notfalls
Drag'n'Drop gehört haben.

> Davon abgesehen würde es selbst unter Linux erhöhte Aufmerksamkeit
> erfordern.

Echt? Das würde mich wundern. Ein simples Kopieren des bin
Verzeichnisses an eine beliebige Stelle des Zielsystems tut das, was man
erwartet: funktionieren. Und jetzt komm mir bitte nicht wieder mit
Linux. Genau das habe ich nämlich gerade kürzlich auf einer Windoof
Büchse erledigt.

> Und schlussendlich hat er selbst gesagt, er ist halt die arme Sau, an
> der der Job hängengeblieben ist, er ist nur der dumme Admin, nicht der
> Softwareentwickler. Wie's in so einer Firma halt ist.

Muß man Softwareentwickler sein, um einen Server zu administrieren? Er
soll ja keine SQL-Statements schreiben, deren Ergebnis den Lauf der Welt
beschreiben, sondern die MySQL administrieren. Und zwar den Teil, bei
dem man nicht eine Zeile Code (welcher Sprache auch immer) schreiben muß.
Wenn das nicht die Aufgabe eines Admins ist, weiß ich auch nicht, was
der sonst tun soll. Papier in den Drucker legen, wenn er keins mehr hat?

> Also etwas Zurückhaltung beim Fingerzeigen... danke...

Genau genommen war es ja ein Kompliment. Ich traue dem OP mehr zu , als
du ;)

Grüße,
Dominik

Re: Teil einer mySQL-Abfrage an PHP-Variable hängen? Geht das?

Dominik Echterbruch schrieb:

> Joachim Durchholz schrieb:
>
>> Seufz.
>> Warum nehmen die Leute immer an, dass das, was für sie piepeinfach ist,
>> das für jeden anderen auch sein muss...

Tut ja niemand.

> Zum Beispiel, weil er auf dem falschen Arbeitsplatz sitzt, wenn er
> solche Dinge nicht beherrscht.

Das trifft's schon eher.

>> Der Mann arbeitet schließlich mit Windows, wie man zwischen den Zeilen
>> lesen konnte.
>
> Selbst die dürften schon mal was von der DOS-Box oder notfalls

Die heißt schon seit XP (oder NT?) "Eingabeaufforderung" :-)

Gruß. Claus

Re: Teil einer mySQL-Abfrage an PHP-Variable hängen? Geht das?

Dominik Echterbruch schrieb:
> Joachim Durchholz schrieb:
>> Warum nehmen die Leute immer an, dass das, was für sie piepeinfach
>> ist, das für jeden anderen auch sein muss...
>
> Zum Beispiel, weil er auf dem falschen Arbeitsplatz sitzt, wenn er
> solche Dinge nicht beherrscht.

Dafür können die Leute selbst in der Regel am allerwenigsten.
Ich habe auch mal beim Einstellungsgespräch erwähnt, dass ich viel
Erfahrung mit Turbo Pascal habe, und wurde dann dem Kunden als "unser
Delphi-Experte" verkauft. Idiotischerweise noch mit "der Mann arbeitet
bei Ihnen im Büro", woraufhin der Schwindel natürlich innerhalb von zwei
Wochen aufflog... meistens liegt sowas daran, dass auf Teufel komm raus
Versprechungen gelogen werden, die die Mitarbeiter dann irgendwie wahr
zu machen haben :-(

>> Davon abgesehen würde es selbst unter Linux erhöhte Aufmerksamkeit
>> erfordern.
>
> Echt? Das würde mich wundern. Ein simples Kopieren des bin
> Verzeichnisses an eine beliebige Stelle des Zielsystems tut das, was man
> erwartet: funktionieren.

Die Installation ist natürlich trivial, aber beim Benutzen muss man
aufpassen, nicht dass man im Versehen doch die falsche Version von
mysqldump erwischt.

Bei einer Windows-nativen Installation könnte es auch Schwierigkeiten
mit der Windows-typischen DLL Hell geben. Das hängt davon ab, wie die
DLLs von mysql organisiert sind (wo sie gespeichert sind, wie sie
benannt sind, welche womit kompatibel ist usw.)

Der eigentliche Punkt ist, dass jede weitere Komplikation die Dinge
weiter erschwert, selbst wenn sie (eigentlich) trivial ist.
Ich hab schon oft genug gesehen, wie jemand, der sich grad in ein neues
Aufgabengebiet einarbeiten muss, unter einer Fülle an Details begraben
wurde und irgendwann frustriert aufgegeben hat.
(Der OP scheint nicht zu dieser Kategorie zu gehören, aber das war
anfangs nicht klar.)

> Und jetzt komm mir bitte nicht wieder mit Linux.

Nö, unter Windows ist es in der Regel nur etwas schwieriger wegen dem
Registry-Geraffel. Mit cygwin hat man die Windows-typischen Probleme
natürlich nicht, dafür dann aber cygwin-typische. Unterm Strich besteht
eben wieder die Gefahr des Ersaufens in zu vielen Details. (Deswegen
halte ich generell wenig davon, jemandem mit einem Problem ein anderes
Werkzeug zu empfehlen. Meistens hat der hinterher mehr Probleme als
vorher - umsteigen sollte man nur dann, wenn's grad nicht an allen Ecken
brennt und man die Zeit hat, sich mit den Problemchen auch wirklich
auseinanderzusetzen.)

Grüße
Jo