backup mit phpmyadmin nicht möglich

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • backup mit phpmyadmin nicht möglich

    hi!

    stehe kurz vor einem provider-umzug und wollte sämtliche daten meiner datenbank auf meinen lokalen rechner überspielen. ein backup zu erzeugen und lokal einzuspielen hat bislang immer geklappt.

    ich habe mir nun die aktuellste xampp version gezogen, da sie die selbe phpmyadmin-version enthält, wie auch mein künftiger provider.

    das problem ist nun, dass der text in meinen php-scripts nur verstümmelt angezeigt wird, d.h. sobald ein umlaut im text vorkommt wird der rest einfach abgeschnitten und nicht angezeigt.

    aus: "verstümmelt" wird also "verst

    der text ist BTW auch innerhalb der tabellen verstümmelt.

    woran kann das liegen? falscher zeichensatz? wie lässt sich das beheben? am webserver lässt sich der zeichensatz beim erstellen des dumps leider nicht einstellen. lokal dagegen sehr wohl. hab jedoch schon sämtliche einstellungsmöglichkeiten durchprobiert und funktioniert hat keiner so recht.

    phpmyadmin-version am derzeitigen webserver: 2.5.7-pl1 (MySQL 4.0.14)
    phpmyadmin-version lokal: 2.6.0-pl3 (MySQL 4.1.8-nt)

    habe nun testhalber auch versucht das backup mit einem anderen tool zu erstellen (mysqldumper), das ergebnis ist jedoch das selbe

    bitte um hilfe!


    ps: das dump-file mit textpad zu öffnen und im UNIX format mit UTF-8 zeichensatz zu speichern in lokal mit phpmyadmin 2.6.0 wieder einzuspielen funktioniert übrigens auch nicht wie gewünscht

    "Après-Ski" wird beispielsweise dann so dargestellt: "Après-Ski"

  • #2
    kannst du nicht mit Confixx, oder was du hast, die DB-Daten an sich sichern?
    Ich kann mir die packen lassen und dann per FTP downloaden
    ... dann kannst du sie entweder lokal dumpen, oder direkt (als Restore) (wenn dein neuer Provider das unterstützt) hochladen.
    [COLOR=royalblue]Ein großes DANKE an alle, die sich auf selbstlose Weise im Forum einbringen.[/COLOR]

    [COLOR=silver]btw: REAL PROGRAMMERs aren't afraid to use GOTOs![/COLOR]

    [color=indigo]Etwas ernster, aber auch nicht weiter tragisch, sieht die Situation bei Software-Patenten aus. Software-Patente sind eine amerikanische Erfindung und stehen auf dem selben Blatt wie genveränderte Babynahrung, die im Supermarkt nicht mehr als solche gekennzeichnet werden soll, um die Hersteller nicht gegenüber denen natürlicher Produkte zu diskriminieren ...[/color]
    (from here)

    Kommentar


    • #3
      ich hab kein confixx, da ich nur ein shared-hosting-service nutze. das ist ausreichend für mich. datenbank-dumps hab ich bislang immer mit phpmyadmin erstellt und diese ließen sich auch problemlos ohne darstellungsprobleme wieder einspielen.

      ob ich phpmyadmin, mysqldumper, o.ä. verwende ist dabei egal. beim einspielen des backups geschehen diese wunderlichen dinge, nicht beim sichern die daten liegen in den dumps ja lesbar vor beim einspielen werden sie verstümmelt und ich hab keine ahnung wieso.

      wenns lokal nicht funktioniert funktionierts beim neuen provider aller voraussicht nach auch nicht. und solang ich das lokale problem nicht beseitigt habe kann ich nicht umziehen.

      Kommentar


      • #4
        Original geschrieben von php_rookie
        beim einspielen des backups geschehen diese wunderlichen dinge, nicht beim sichern
        scheint sich um ein encoding-problem zu handeln.

        verwenden beide DBs das gleiche charset?
        arbeitest du in beiden PMAs mit dem gleichen encoding?
        I don't believe in rebirth. Actually, I never did in my whole lives.

        Kommentar


        • #5
          alternativ kannst du beim darstellen der daten mit deinem script einen header() mit einem anderen content-type senden.

          wenn der apache beispielsweise standard UTF-8 sendet, kannst du das mit header() überschreiben.

          probier das mal bitte auch aus.
          INFO: Erst suchen, dann posten![color=red] | [/color]MANUAL(s): PHP | MySQL | HTML/JS/CSS[color=red] | [/color]NICE: GNOME Do | TESTS: Gästebuch[color=red] | [/color]IM: Jabber.org |


          Kommentar


          • #6
            verwenden beide DBs das gleiche charset?
            arbeitest du in beiden PMAs mit dem gleichen encoding?
            ich kann es wie gesagt nur lokal einstellen welches charset verwendet werden soll. am webspace fehlt mir diese möglichkeit. gibt es denn kein tool mit dem man ein bestehendes textfile entsprechend umwandeln kann?
            alternativ kannst du beim darstellen der daten mit deinem script einen header() mit einem anderen content-type senden.

            wenn der apache beispielsweise standard UTF-8 sendet, kannst du das mit header() überschreiben.
            das war mir jetzt ein paar km/h zu schnell ^^ könntest du mir das bitte nochmals etwas langsamer erklären was genau ich machen muss?

            Kommentar


            • #7
              Original geschrieben von php_rookie
              gibt es denn kein tool mit dem man ein bestehendes textfile entsprechend umwandeln kann?
              natürlich, das sollte jeder gute texteditor können, umwandeln von unicode/utf8 nach ascii oder umgekehrt, etc. pp.

              aber in was willst du umwandeln, wenn du offenbar noch nicht mal weißt, welches encoding wo verwendet wird?
              I don't believe in rebirth. Actually, I never did in my whole lives.

              Kommentar


              • #8
                Original geschrieben von php_rookie
                könntest du mir das bitte nochmals etwas langsamer erklären was genau ich machen muss?
                http://php.net/header
                INFO: Erst suchen, dann posten![color=red] | [/color]MANUAL(s): PHP | MySQL | HTML/JS/CSS[color=red] | [/color]NICE: GNOME Do | TESTS: Gästebuch[color=red] | [/color]IM: Jabber.org |


                Kommentar


                • #9
                  natürlich, das sollte jeder gute texteditor können, umwandeln von unicode/utf8 nach ascii oder umgekehrt, etc. pp.

                  aber in was willst du umwandeln, wenn du offenbar noch nicht mal weißt, welches encoding wo verwendet wird?
                  in UTF-8 wie im einleitenden posting erwähnt. nur funktioniert die umwandlung mit textpad im UNIX format und UTF-8 dann trotzdem nicht. lokal kann ich das quellformat ja einstellen.

                  @ abraxax: danke, schau ich mir mal an.

                  Kommentar


                  • #10
                    das einlesen in die datenbank funktioniert jetzt. sämtliche umlaute sind korrekt vorhanden. sobald ich einen datensatz aus der datenbank hole und mit php auszugeben versuche erhalte ich für äüö folgende ausgabe äüö (datensatz wurde mit phpmyadmin utf8-codiert eingegeben). das ganze ist also ein reines darstellungsproblem, das ich unter MySQL 4.0.14 nicht hatte unter version 4.1.8-nt dagegen sehr wohl.

                    wie lässt sich das beheben? bitte nochmals um hilfestellung!

                    Kommentar


                    • #11
                      wenn du die daten als utf-8 in dei DB geschrieben hast, solltest du sie auch als utf-8 ausgeben ... also encoding der seite anpassen.
                      I don't believe in rebirth. Actually, I never did in my whole lives.

                      Kommentar


                      • #12
                        also die ausgabe mit utf8_decode() korrigieren?

                        ich denke ich kann das problem jetzt eingrenzen. der mysql-server meinens providers läuft unter iso-8859-1, lokal hab ich xampp laufen mit de-uft-8 codierung.

                        weiß jemand wo genau man im xampp-paket das standard-charset der mysql-datenbank ändern kann? die my.ini datei von utf-8 auf latin1 zu stellen funkioniert nicht so ganz.

                        Kommentar


                        • #13
                          okay, ich hab den fehler! die datei my.cnf im ordner /xampp/mysql/bin muss an folgender stelle angepasst werden:

                          default-character-set=latin1

                          statt

                          default-character-set=utf8 (defaulteintrag)

                          dann klappts auch wieder mit der darstellung der umlaute.

                          Kommentar

                          Lädt...
                          X