NinaG wrote:Ich finde es erstaunlich, dass du gleich persönlich beleidigend wirst.
Weil es genauso eine feiste(!) Beleidigung an die Entwickler von phpmyadmin und Xampp ist, es wäre eine "Bankrotterklärung", wenn Du Deinen Export nicht damit hinbekommst. Was soll das denn? Da programmieren sehr engagierte und sicherlich auch gute Leute eine gute Software (für "Nothing"), da hat "Bankrotterklärung" nichts verloren. Das finde ich arrogant, ja, das empfinde ich eben so. Das kann man auch ganz anders formulieren. Und es trifft ja auch nicht zu.
NinaG wrote:Abgesehen davon denke ich, dass ich nichts ungewöhnliches verlange: Ich verlange nur, dass die Export-Funktion von phpMyAdmin so funktioniert, dass ich das Ergebnis auf dem Online-Webspace auf einem phpMyAdmin derselben Version über die dortige Import-Version importieren kann
Genau das siehst Du falsch, phpmyadmin kann nur gewisse "Defaultannahmen" treffen, die aber nicht in jedem Kontext die optimale Lösung darstellen (das geht nun einmal technischt nicht, dafür spielen zu viele Komponenten eine Rolle). Deswegen muss man dann (und da gehts dann ans Eingemachte, weil man dann wirklich wissen muss, was wo passiert und wie die Daten übertragen werden), wenn diese Defaultangeben nicht reichen, mit dem entsprechenden Optionen und SQL Kommandos die Ausgabe entsprechend beeinflussen.
NinaG wrote:Anders ausgedrückt: Ich nutze XAMPP und phpMyAdmin seit rund 10 Jahren erfolgreich und gehe dabei immer den Weg über den Export/Import von phpMyAdmin. Die genannten Probleme treten bei mir erst seit XAMPP 1.8.3 auf.
Und Du benutzt seit 10 Jahren die gleichen Umgebungen, insbesondere auch Contao? Das sind ja so viele Dinge zu berücksichtigen und das ist ja kein Zufall, dass Contao einen eigene Export anbietet - die wissen natürlich, was sie da treiben und was sie brauchen. Wenn Du die Stelle im Source von Contao findest, dann kannst Du notwendigen Einstellungen nach Phpmyadmin übernehmen.
NinaG wrote:PS: Und ja, "Bankrotterklärung" war sicher etwas hart formuliert, aber einfach meinem gestrigen Frust geschuldet. Ich empfinde das gesamte XAMPP-Projekt, phpMyAdmin und Co natürlich als exzellente Tools, die ich deshalb auch schon jahrelang gerne einsetze. Wenn das dann plötzlich nicht mehr klappt, kommt Frust auf, der sich bei mir etwas angestaut und gestern unter dem Druck entladen hatte. Falls ich damit einem Programmierer des jeweiligen Projekts unabsichtlich auf die Füße getreten bin: Sorry, war nicht so gemeint.
Na also, geht doch. Du darfst auch nicht vergessen, Du kommst hier ganz neu rein und das erste was schreibst, ist "Bankrotterklärung". Damit kann sich nicht wirklich beliebt machen. Wenn Du schon tausende von Problemen gelöst hättest und die Schwächen und Stärken der Produkte kennst und es gäbe wirklich eine furchtbare Schwachstelle, die seit Jahren nicht behoben ist o.ä., dann kann man das von mir aus schreiben. Aber nicht "einfach so". Normal hätte ich auch nur geantwortert "dann benutze es eben nicht", es zwingt Dich ja keiner.
NinaG wrote:Ernsthaft aus dem Bestreben das zu Verstehen und zu Lernen gefragt:
Wie kommt es, dass ich im selben UTF8-Editor einmal
";H9Š¥ãªÖ T¥öi" sehe, wenn das Feld mit phpMyAdmin exportiert wurde, aber
"0x3b4839a6a51411e3aad60c54a510f669" sehe, wenn ich das Feld mit einem anderen Exporter (der backupDB-Extension von Contao) exportiert habe?
Weil phpmyadmin offensichtlich eine binäres Format exportiert, aber der Exporter von Contao exportiert NICHT das native Binärformat, sondern wandelt es offensichtlich in einen sog. "Hexdezimal-Dump" um. Und das deutet schon einmal ganz sicher darauf hin, dass es also mit diesem Binärformat Probleme geben kann (ich weiß ja auch nichts darüber, ich weiß nicht, was das portiert wird). Aber man wandelt binäre Daten nicht aus Spaß in lesbare Hexadezimalschreibweise um, sondern um irgendeinem Problem vorzubeugen. Offensichtlicht gibt es dann im Contao auf dem Zielrechner auch ein Importscript und das wandelt dann diese Hexadezimaldaten in Binärdaten um.
Ich habe ja keine Ahnung, was da wo gespeichert wird und was benötigt wird, aber Binärdaten können in bestimmten Zusammenhängen zu Problemen führen. Ein Beispiel: wenn ein Byte dieser Binärdaten ein sog. "Carriage Return" darstellt, dann kann das bei einer unsauber eingestellten FTP Verbindung zu Problemen führen, weil dieses Zeichen einen Zeilenumbruch bedeutet.
Ein weiteres Problem ist die interne Darstellung von Integerzahlen auf einem Computer. Die hängt vom Prozessor ab, das können zwischen zwei und acht Byte sein, die zu einer Zahl zusammengefasst werden und es gibt Prozessoren (dazu gehören auch die Intelprozessoren), die betreiben ein sog. "Byte-Swapping". Da werden (aber nur im Kontext von Integerzahlen) die Bytes nicht von "links nach rechts" sondern von "rechts nach links" zu einem Wert zusammengefasst. Auf den Motorola-Prozessoren (die waren früher in Apple Rechnern u.a.) wird diese Login NICHT betrieben. In diesem Zusammenhang können schlimme Sachen passieren - und um das zu vermeiden, wird auf der Quellmaschine die Binärdaten in ein Textformat umgewandelt (nämlich genau dieser Hex-Dump), wird dann auf den Zielrechner gebracht und wird dort wieder zurückgewandelt.
Offensichtlich sind diese Binärdaten auch den Entwicklern von Contao nicht geheuer, deswegen konvertieren sie diese. Wenn sie die Daten rein mit SQL Statements konvertieren, kann man das mit Phpmyadmin auch nachbilden. Wenn aber komplexe Berechnungen in PHP o.ä. erfolgen, dann solltest Du ganz auf Phpmyadmin in diesem Kontext verzichten. Der Export in sog. "*.sql" Dateien ist immer ein Export im Textformat, denn nachher soll ja der Mysql Interpreter die Daten zeilenweise einlesen. Und mit Binärdaten in Textdateien geht das an allen möglichen Ecken kaputt, das geht einfach so nicht.
Last not least (hatte ich oben schon angedeutet): wenn die Rechner ähnliche Architektur besitzen (Intel Prozessoren 64 Bit beispielsweise) und wenn die MySQL Releases der Quellmaschine und der Zielmaschine nicht zu weit auseinanderliegen, dann kannst Du (und das mit Abstand das einfachste) das komplette data-Verzeichnis einfach übernehmen. Kein Umweg über *.sql Dateien, sondern die nativen Datenbanken einfach direkt übertragen.
