Posts by Volker S

    Hi,

    da ich mir nicht sicher bin, ob zwangsumgestellt wird (und wenn, dann wann?) frage ich hier mal nach. Ich habe ein Webhostingpaket und benutze php 5.6.


    Grüße
    -volker-

    H6G ,

    dein Vorschlag für eine kostengünstige Variante eine Inklusivdomain loszuwerden wäre also: Irgendwo ein sehr günstigen Konkurrenten zu wählen (hier war ja vor Kurzem auch ein Angebot mit 1,44@/Jahr für eine .de Domain) - die Inklusivdomain dort hinzuziehen - und dann sofort kündigen.:)


    Aber es müssen doch auch Inklusivdomains jedes Jahr verlängert werden. Ich verstehen nicht, warum netcup an diesem Termin keine Kündigung der Inklusivdomain transparent anbieten kann. Ein close und eine Löschung wären mit einem einfachen Klick im ccp machbar. Aber naja - ist halt so.

    das funktioniert nicht. Inklusivdomains sind an den Tarif gebunden. Wir bezahlen für de-Domains z.B. Registrierungsgebühren und haben Laufzeiten die eingehalten werden müssen. Aus dem Grund können einmal genutzte Plätze nicht neu belegt werden.

    Aber wenn man ganz normal eine Domain von den Inklusivdomains kündigt, dann verschwindet diese doch nach der Laufzeit aus dem Paket (weil sie einfach nicht erneut registriert wird). Nur wenn man das ausserhalb der Laufzeit verlangen würde, wäre das eine Extraleistung die - wenn überhaupt - auf Kulanz durchgeführt wird. Habe ich doch so richtig verstanden, oder?


    -volker-

    frostschutz ,


    Du bist da 100% auf der richtigen Spur. Genau diesen Einwand habe ich auch schon im Netz gefunden (bei einem anderen ähnlichem Problemfall)


    Zitat:

    "Nach meiner Erfahrung sieht das so aus wenn Strings in einem

    Multibyte-Zeichensatz (z.B. UTF-8) vorliegen und in einer DB-Spalte

    abgelegt werden, die einen Singlebyte-Zeichensatz hat. Zwei oder drei

    Bytes ergeben zusammengenommen eigentlich ein Sonderzeichen – der

    Singlebyte-Zeichensatz interpretiert aber jedes Byte einzeln und

    speichert sie so."


    Ich habe das für mich dann so interpretiert, dass ich das Multibyte-Format der neuen db vor der Migration meiner alten db in die Kollation 'utf8_general_ci' umstelle, um dann erneut ein Migrationsversuch zu starten. Da ich genau auf diese Kollation keinen Einfluss habe (Die allgemeine Einstellung 'utf8mb4_unicode_ci' lässt sich als User nicht verändern - siehe auch hier mein Eröffnungsthread) habe ich mal ein Ticket aufgemacht (nur die 'Operationen' und die Kollationen der Tabellen selber kann man umstellen).


    Der Dump meiner alten db wurde tatsächlich mit MySQLDumper vollzogen, welcher schon länger nicht mehr weiter entwickelt wird. Wenn ich ein Dump bei meinem alten Hoster mit PHPMyAdmin mache (welches hoffentlich dann das Multibyte-Format unterstützt muss ich doch vor dem Dump meine gange db in das Multibyte-Format umwandeln (stimmt doch, oder?). Aber gleichzeitig habe ich von irgenwo auch gehört, dass ich hier mit PHPMyAdmin keine db > 2 MB (komprimiert) migrieren kann. Meine db ist aber > 5 MB. Ich werde mal den netcup-Support hierhin verlinken - vielleicht fällt dem noch was ein.


    -volker-


    Nachtrag: Ich selber kann meine db gar nicht löschen - auch nicht mittels Konsole und drop-Befehl. Da muss ich wohl ein Ticket für aufmachen.

    Die neue db dann am Besten (vor dem Importieren) so einstellen, wie die alte Datenbank (siehe Eröffnungsthread). Oder soll ich alles auf utf8_unicode_ci stellen.


    Allerdings (fällt mir gerade ein): Die anderen beiden Homepages (sind cms-Systeme) laufen ja anscheinend fehlerfrei mit den Einstellungen der neuen db. Ich werde das mal überprüfen, und auch mal bei einem cms ein Umlaut abspeichern. Jepp, das cms speichert die Umlaute richtig in die db ab und holt sie auch so wieder raus. Dann muss es also doch per Script zu lösen sein. Ich schau mir aber auch noch mal die Tabellen des cms an, unter welcher Kollation das abgespeichert ist.

    Hi Peter,


    für den Ex -und Import benutze ich MySQLDumper. An der Benutzung von phpmyAdmin lag es also nicht.


    aNewUser ,

    kann schon sein - bisher (ich glaube seit 10 Jahren steht die Seite im Netz) ist das noch nicht passiert. Außerdem mache ich täglich Backups. Aber Du hast schon recht - ne Profiseite ist das natürlich nicht.


    ...macht mal Vorschläge, wie ich den Kollationsfehler weg bekomme. db komplett löschen und neu importieren?


    -volker-

    killerbees19 ,


    keine Ahnung, ich habe jedenfalls mittels .htaccess php5.6 eingestellt (AddHandler x-httpd-php56 .php). Und dieses .htaccess ist auch im netcup-Verzeichnis enthalten. Dann müsste doch auch hier 5.6 laufen - oder nicht? :)

    Ich habe mal gerade auf palmenstandorte ein phpinfo() abgesetzt - die Einstellung wurden also mit .htaccess übernommen. PHP-Version ist 5.6.36


    H6G ,

    mein Fehler war wohl diesbezüglich bei netcup eine Datenbank anzulegen und sofort zu importieren. Besser wäre es wohl gewesen erst mal alles bei der neuen db auf utf8_unicode_ci umzustellen. Trotzdem, vorm Import und nach dem Import haben beide Tabellen die gleiche Kollation (utf8_general_ci).

    Was ist Deine Empfehlung? Ganze db löschen und neu importieren? Alles auf utf8_unicode_ci einstellen - ich schätze die Tabelle wird dann trotzdem mit ihrem Zeichensatz utf8_general_ci importiert - nur ist dann wenigsten die Verständigung zwischen Client und Server einheitlich.


    -volker-

    Hi liebe Forenmitglieder,


    bin gerade nach netcup migriert und habe meine 3 Homepages nebst Datenbanken auch schon auf dem Webspace abgelegt. Das Problem ist meine gebastelte interaktive Karte. Diese will auf einmal nicht so wie früher - und das ist definitiv ein Kollationsproblem. Bloß kenne ich mich mit den utf8-Derivaten nicht so ganz aus. Meine alte Datenbank habe ich einfach hier in die neu angelegte Datenbank migriert.


    Hier mal die Einstellungen der alten SQL-db:

    Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8_general_ci

    Operationen: utf8_unicode_ci

    besagte Tabelle: utf8_general_ci


    Das wurde in die netcup-db migriert, welche diese Einstellungen hatte (und natürlich immer noch hat:

    Startseite (allgemeine Einstellungen: Zeichensatz der MySQL-Verbindung): utf8mb4_unicode_ci

    Operationen. utf8_general_ci

    besagte Tabelle: utf8_general_ci


    Wie man sieht hat die besagte Tabelle also bei netcup die gleiche Kollation wie bei meinem alten Hoster. Sollte also hinhauen - weit gefehlt. Die HTML-Seite wurde zwar angezeigt, aber die Datenbankabfrage (Marker werden auf eine Landkarte gesetzt) funktionierte nicht. Dabei werden die Datensätze in eine XML-Datei geparsed und ich habe schnell herausfinden können, wann der Parser abgebrochen hat. Das war an einem Umlaut (ü). Damit war klar was das Problem war, und da ich mit dem mistigen Kollationen immer auf Kriegsfuß stehe, habe ich mein Script angepasst (an den Kommentaren ersichtlich was umgestellt wurde).

    Hier das Script: phpsqlinf_result.php


    So, nun wurden alle Marker wieder angezeigt. Leider bleibt ein Kollationsproblem beim Editieren der Marker - besser gesagt beim wieder reinschreiben in die Datenbank. Auch hier ist das php-Script mit einem Kommentar versehen. Geschrieben wird mittels HTML-Post-Methode. Meta-Tag und auch Header stehen auf utf8.

    Hier das Script: edit_reg.php


    ...da ich die Seite schon vor langer Zeit gemacht habe, bin ich nun etwas eingerostet. Wie gesagt, es ist ein Kollationsproblem, weil ja von Anfang an das Einlesen aus der Datenbank an Umlauten scheiterte - ich seh vor lauter utf8 Tags aber nicht den Fehler. Vielleicht könnt Ihr mir helfen.


    Ihr könnt gerne mal selber ein paar Marker setzten und das Ergebnis überprüfen (rausholen funktioniert / reinschreiben da verhaut er die Umlaute).

    Hier die Seite (die vorher funktionierte): www.palmenstandorte.de


    -volker-