Datenbank Manager für modified eCommerce Shopsoftware

[web28]

Hab die 1.71 auch nochmal offline genommen um schlimmeres zu verhindern.

Das Problem ist, dass es dadurch hier nich mehr weitergeht, der von phpGuru angesprochene "Fehler" existiert beim XTC Backup schon immer. Deshalb halte ich das für keinen Fehler, es wurden ja auch schon mit der 1.60 und 1.70 fehlerfreie Restores durchgeführt.

Das ist ein Auszug aus einem Original XTC Backup (mit der Originaldatei erstellt)

Code: PHP  [Auswählen]

insert into configuration (configuration_id, configuration_key, configuration_value, configuration_group_id, sort_order, last_modified, date_added, use_function, set_function) values
('1', 'STORE_NAME', 'TESTSHOP', '1', '1', NULL, '0000-00-00 00:00:00', NULL, NULL);

Auch hier sind die Ziffern 1 alle escaped.

Ich lade hier noch eine 1.71a hoch, hier ist nur die Pflege der Versionsnummer im $schema hinzugekommen.

Aufgrund der Problematik bitte nur in einem Testshop testen, und auch nur wenn man vorher ein anderes Backup der Datenbank durchgeführt hat. Entwender mit MySqlDumper oder direkt aus dem phpAdmin.

Gruss Web28

[EDIT Tomcraft: Module im ersten Beitrag aktualisiert]

[phpGuru]

Das ist kein Fehler. INT Felder haben nicht in Hochzeichen zu stehen. Kannst du bei mySQL und php nachlesen.

Die original backup.php kann ich auch nicht verwenden, da diese den ganzen Schrott der INSERT INTO vor jede Zeile schreibt und somit das ganze aufbläht ohne Ende.

Weiterhin änderst du in Textfeldern " in \". Das brauchst du nicht. Der komplette String eines Textfelds kommt in einfachen Hochzeichen und zwischendurch vorkommende " brauchen dann nicht escaped zu werden. Absonsten machst du dir den ganzen String kaputt. Sieh dir doch einfach mal ein Backup, welches mit phpMyAdmin erstellt wurde an. Warum macht man sich eigentlich den ganzen Stress und bindet den phpMyadmin nicht in den Admin Bereich mit ein?

z.B.

Code: PHP  [Auswählen]

'
<div align="left"><font face="Verdana" size="1" color="#000000">'

[Tomcraft]

phpMyAdmin in den Backend einbinden? Nein, keine gute Idee... da kann der unerfahrene Benutzer zuviel kaputt machen!
Dann eher MySQLDumper!

[phpGuru]

Sorry etwas zu dirty geschrieben. Man könnte sich aber die Backup Funktion aus phpmyAdmin herausziehen oder wie Du bereits schriebst den Dumper.

[web28]

Wir sind uns ja einig, das die jetzige Backupfunktion verbessert werden muss.

Kurzfristig kann man ja zuerst an der backup.php arbeiten, langfristig wäre die Integration vom MySQLDumper auf jeden Fall sinnvoll.

Hier mal deb Codeauszug des Exportteils aus der backup.php 1.71a

Code: PHP  [Auswählen]

$tables_query = xtc_db_query('show tables');
        while ($tables = xtc_db_fetch_array($tables_query)) {
          list(,$table) = each($tables);

                  //BOF NEW TABLE  STRUCTURE
                  $schema .= 'drop table if exists ' . $table . ';' . "\n" ;
                  $res = mysql_query("SHOW CREATE TABLE ".$table);
                  $createtable = mysql_result($res, 0, 1);
          $schema .= $createtable;
                  $schema .= " ;\n\n";
                  //EOF NEW TABLE  STRUCTURE

                  $table_list = array();
          $fields_query = xtc_db_query("show fields from " . $table);
          while ($fields = xtc_db_fetch_array($fields_query)) {
            $table_list[] = $fields['Field'];
          }          

          // Dump the data
          $rows_query = xtc_db_query("select " . implode(',', $table_list) . " from " . $table);
                  //BOF OPTIMIZE OUTPUT
                  $flag = true;
          while ($rows = xtc_db_fetch_array($rows_query)) {
            //$schema_insert = 'insert into ' . $table . ' (' . implode(', ', $table_list) . ') values (';
                        if ($flag) $schema .= 'insert into ' . $table . ' (' . implode(', ', $table_list) . ") values\n";
                        $flag = false;
                        $schema_insert = "(";
                  //EOF OPTIMIZE OUTPUT
            reset($table_list);
            while (list(,$i) = each($table_list)) {
              if (!isset($rows[$i])) {
                $schema_insert .= 'NULL, ';
              } elseif ($rows[$i] != '') {
                $row = addslashes($rows[$i]);
                                //$row = ereg_replace("\n#", "\n".'\#', $row); //Original xtc
                $row = preg_replace("/\n#/", "\n".'\#', $row); // Hetfield - 2009-08-19 - replaced deprecated function ereg_replace with preg_replace to be ready for PHP>= 5.3
                //$row = str_replace("\r\n", '\r\n', $row);
                                $schema_insert .= '\'' . $row . '\', ';
              } else {
                $schema_insert .= '\'\', ';
              }
            }
                  //BOF OPTIMIZE OUTPUT
            $schema_insert = preg_replace('/, $/', '', $schema_insert) . '),' . "\n"; // Hetfield - 2009-08-19 - replaced deprecated function ereg_replace with preg_replace to be ready for PHP>= 5.3
            $schema .= $schema_insert;
          }
                  if (!$flag) $schema =substr($schema, 0, -2) . "; \n";; //letztes Komma  durch Semikolon ersetzen  -2 wegen Zeilenumbruch (Komma ist vorletztes Zeichen)
                  //EOF OPTIMIZE OUTPUT
          $schema .= "\n";
        }

Vielleicht hat ja jemand eine Idee, wie man die angesprochenen Fehler beheben kann

Gruss Web28

[speedy]

sorry, aber ich würde da keine Zeit investieren in diese Sache und einfach MySQLDumper einbinden oder zumindest darauf verweisen.
Die xtc-eigene Funktionalität würde ich komplett rausnehmen.

Den Backups vom Datenbank-Manager würde ich niemals trauen. Das müsste umfassend getestet werden, das geht nicht wenn hier 2-3 Leute testen.
Der MySQLDumper ist weitläufig bekannt und arbeitet seit Jahren zuverlässig, auch bei großen Datenbanken. Es reicht ja, wenn die von MySQLDumper da Zeit für Entwicklung investieren.

[web28]

Den Backups vom Datenbank-Manager würde ich niemals trauen.

Warum denn das? Diese Funktion gibt es in OSC, allen XTC Forks und und und...

Wenn das wirklich nicht funktionieren würde, wäre das allgemein bekannt.

Vom Grundprinzip funktioniert das auch, man kann aber immer etwas verbessern.

Die bisherigen Version 1.60 - 1.71 entsprachen auch einer Version von einem anderen XTC-Fork. Auch hier werden bei der Sicherung numerische Datenbankeinträge alle in Hochkommata gesetzt und bestimmte Zeichen mit Backslash geschützt (addslashes). Aber auch hier kein Aufschrei, dass das nicht sein darf oder der Restore nicht funktioniert! Ich sehe phpGuru mit seiner Meinung da ziemlich alleine, jedenfalls habe ich nichts weiter diesbezüglich gefunden.

Bei mir haben die Restores bisher auch alle problemlos funktioniert.

Trotzdem eine neue Version 1.72:

'tinyint', 'smallint', 'mediumint', 'int', 'bigint', 'decimal', 'float', 'double', 'real'
werden nicht mehr Hochkommata gesetzt - entspricht Backup aus phpMyAdmin
Zeilenschaltung mit \r\n  - entspricht Backup aus phpMyAdmin
Backslashes werden bei " entfernt - entspricht Backup aus phpMyAdmin
Backslashes werden bei ' durch ' ersetzt - entspricht Backup aus phpMyAdmin

Bitte testen und Feedback!

Gruss Web28

[EDIT Tomcraft: Version im ersten Beitrag aktualisiert!]

[Tomcraft]

Noch Probleme gefunden?

Wäre doch ein schickes fearture für die kommende v1.03.

[web28]

Hallo Torsten,

bitte deaktiviere die Version 1.72

Ich habe gestern einen Test mit dem MySQLDumper gemacht. Der Dumper erzeugt das selbe Backupformat wie die Version 1.70!!! Hochkommatas bei Int usw. und escapte Sonderzeichen

Der Dumper ist für mich DIE Referenz für MySQL Backups.

Ich werde also den Backup Manager in den nächsten Tagen nochmals bearbeiten, und dafür die Backup-Routinen vom Dumper einbauen, eine Split- und Timeoutfunktion für große Datenbanken wird es aber nicht geben. Ich werde nur die Auslesefunktionen für die Datenbank einbauen, das ist aber das eigentlich Wichtige.

[Tomcraft]

Gut, dann warte ich auf die nächste/vorherige Version.

[phpGuru]

Ich sehe phpGuru mit seiner Meinung da ziemlich alleine, jedenfalls habe ich nichts weiter diesbezüglich gefunden.

'tinyint', 'smallint', 'mediumint', 'int' etc. sind nun mal keine Strings sondern feste Werte und die werden nicht in in Hochkomma gesetzt. Machst du es kann es zu Problemen kommen (siehe Link unten. Ich schreibe jetzt nicht warum, steht im Link) Darum haben diese ja auch den Typ int tinyint etc. Mal auf die schnelle eines von vielen Erklärungen im Netz zu den mySQL/php Erklärungen gegriffen. Dort kannst du es auch an Hand von Beispielen nachlesen. Davon gibt es Unmengen. Es liegt nur immer daran wonach man sucht, um die richtigen Ergebnisse zu erhalten.

http://blog.parastudios.de/?p=126

Ich habe gestern einen Test mit dem MySQLDumper gemacht. Der Dumper erzeugt das selbe Backupformat wie die Version 1.70!!! Hochkommatas bei Int usw. und escapte Sonderzeichen

Darum gab es da auch in der Vergangenheit Probleme, denn in varchars wurden mit der Maskierung Fehler gemacht.

@speedy
Deine Meinung kann ich so nicht akzeptieren und stimme web28 vollkommen zu. Wir setzten den phpMyAdin seit Jahren professionell ein und die Backups haben immer gestimmt. Es arbeiten an diesem OS Tool seit mehreren Jahren sehr viele Leute und wird auch von php als Referenz genannt. Hätte es dort im Bereich der Backup Routinen Probleme gegeben wäre das bekannt und gefixed. Es ist halt für einen prof. Anwender halt einfacher seine Tools unter einem Hut zu haben. Das schmälert aber nicht die Qualität der Anwendung. Beide Programme verrichten zur Zufriedenheit ihre Dienste. Es kommt aber immer darauf an, was ich von einem Programm erwarte. Sicherlich ist der Dumper für unerfahrene User und für Leute die nur ein zuverlässiges Tool suchen ihre db zu sichern in Ordnung. Für andere ist der Wechsel von einem Datenbankmanager zu einem sep. Backuptool zu umständlich und wünschen sich das ganze unter einer Oberfläche wie phpMyAdmin. Beide Programme Backup Programme sind aber dadurch in ihren Backup Routinen nicht schlechter oder besser.

[Tomcraft]

Ich denke du hast speedy falsch verstanden, er meinte nicht phpMyAdmin, sondern den XTC-Backup-Manager.

Grüße

Torsten

[web28]

Ich habe das ganze Thema mal bei den Experten vom MySQLDumper zur Sprache gebracht.

http://forum.mysqldumper.de/post35621.html#35621

Auf dieser Basis wird es demnächst eine neue Version geben.

@phpGuru
für Dich könnte ich eine "Spezialversion" bereitstellen.

Gruss Web28

[Tomcraft]

schick, schick, schick...

[speedy]

@phpGuru.
Ist so wie Torsten sagt, ich meinte den XTC-Backup-Manager, nicht phpMyAdmin.

Ich traue da lieber dem was seit Jahren zuverlässig unter allen Bedingungen funktioniert. Heißt nicht, dass der XTC-Backup-Manager oder phpMyAdmin nicht funktioniert, aber der MySQLDumper ist die ultimative Lösung in dem Bereich.
Getestet von wohl zehntausenden Usern, gibt wohl nix sichereres. Auch was große DBs und Timeouts angeht.

3-4-5 Leute, die hier ausgiebig testen können nicht alle verschiedenen Datenbank-Umgebungen mit "100%iger" Sicherheit testen.
Mit MySQL Dumper könnte man da ne sichere Lösung annehmen, dabei noch viel Entwicklungszeit und Testzeit sparen.

Das war mein Gedanke