Posts Tagged ‘MySQL’

Freitag, 7. November 2008

Datenbankdump von MySQL 5 nach MySQL 4

Den ursprünglichen Dump stellte ich mit phpMyAdmin her. Leider erlaubt die Web-Applikation nicht, den Charset des Dumps von UTF-8 nach LATIN1 (aka ISO-8859-1) anzupassen.

Deshalb ging es auf die Kommandozeile des Servers:

mysqldump --default-character-set=latin1 --compatible=mysql40 -u {user} -p {db} > dump.sql

Einerseits konnte ich so das Charset des Dumps festlegen (--default-character-set=latin1), andererseits musste ich aber auch auf die Kompatibilität achten (--compatible=mysql40). Leider war es mit letzterem Versprechen nicht wirklich weit her …

Auf Grund eines seit Monaten bestehenden Bugs in MySQL 5 enthielt der mysqldump-Dump Befehle, die MySQL 4.0.x nicht versteht:

SET @saved_cs_client     = @@character_set_client;
SET character_set_client = @saved_cs_client;

… was MySQL 4 folgende Fehlermeldung ausgeben liess:

#1193 - Unknown system variable 'character_set_client'  

Mittels vim (die GUI-Editoren unter Mac OS X mit Syntax-Highlighting kapitulierten vor 4000+ Zeilen) konnte ich den Dump dann doch noch derart zurechtbiegen, dass MySQL 4 die Datei schlussendlich schluckte. Der Befehl dazu lautete:

:g/^SET/d

Via: Vim: Delete every line in the file that does not match a pattern

Dieser vim-Befehl löscht kurzerhand alle Zeilen, die mit SET ... beginnen. Scheint dem Import nicht geschadet zu haben …

Tags:
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Freitag, 22. August 2008

Wenn MySQL unter Mac OS X nicht automatisch startet

Ich habe seit längerem das offizielle MySQL 5.0.45 auf meinem MacBook (Intel mit Mac OS X 10.4.11) installiert. Alles wunderbar – doch bis zum heutigen Tage wurde MySQL bei einem (Re-)Boot nicht automatisch gestartet. Ich musste mich dann immer mühsam zum Preference Pane durchhangeln und dort auf „Start MySQL Server“ klicken (für einmal per GUI, nicht per CLI).

Heute habe ich mir nun zur Aufgabe gesetzt, dieses Problem zu beheben und kann folgenden Lösungsweg aufzeichnen:

  1. Download der neuesten MySQL-Version bei SWITCH: mysql-5.0.67-osx10.4-i686.dmg
  2. Mounten des Disk Images
  3. Doppelklick auf MySQLStartupItem.pkg
  4. # rm -rf /Library/PreferencePanes/MySQL.prefPane
  5. Download des Ersatzes von MySQL.prefPane-leopardfix.zip
  6. Installation des neuen Preference Panes mittels Doppelklick auf MySQL.prefPane

Seither läuft MySQL bei jedem (Neu-)Start.

Via: Bug-Report mit Erläuterungen zum Problem

Tags: , ,
Labels: Allgemein

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 2. Juli 2008

Hostpoint-Problem des Monats: Zeichensalat

Kein Monat vergeht, in dem Hostpoint nicht eine Überraschung parat hat. Während ich im Juni das erste Mal seit langem etwas Positives berichten durfte, war klar, dass im Juli garantiert wieder etwas kaputt gehen musste.

Und tatsächlich: Heute erhalte ich ein Mail eines Kunden, der über komische dargestellte Sonderzeichen flucht. Nach dem ich die Homepage angesurft habe, kann ich das Problem bestätigen: Irgendwie scheinen da UTF-8 und ISO-8859-1 durcheinander gekommen zu sein. Seit sechs Jahren hat die Web-Site keine Probleme mit Zeichensätzen aufgewiesen, doch nun ist über Nacht wohl etwas „kaputt“ gegangen.

Soweit ich erkennen konnte, liegt das Problem darin begründet, dass mysql_query() neu nicht mehr ISO-8859-1-kodierte Zeichensätze zurückliefert, sondern UTF-8. Das HTML-Dokument sagt von sich aber, dass es in ISO-8859-1 kodiert ist – und htmlentities() erwartet auch ISO-8859-1. Ah, und die Tabellen-Spalten weisen ebenfalls latin1_german1_ci als Kodierung auf (jedenfalls sagt mir das phpMyAdmin so).

Temporärer Workaround

mysql_query("SET NAMES latin1");

… zuoberst in der index.php (natürlich nach dem Initialisieren der Datenbankverbindung!)

Jetzt klappt es wieder mit den Zeichensätzen.

Mal schauen, was sich Hostpoint für den kommenden Monat einfallen lässt.

Tags: , , ,
Labels: Schweiz

1 Kommentar | neuen Kommentar verfassen

Dienstag, 10. Juni 2008

Apache 1.3, MySQL 5 und PHP 5 unter Mac OS X auf UTF-8 trimmen

Mittlerweile habe auch ich den AMP-Stack auf meinem MacBook installiert und entwickle damit Web-Applikationen. Damit es bezüglich den Zeichensätzen koscher zu und her geht, musste ich folgende zwei Anpassungen an der Konfiguration vornehmen:

Apache 1.3

(Ich verwende aus Faulheit den mit Tiger mitgelieferten Apache – leider halt noch nicht 2.x)

In der /etc/httpd/httpd.conf wird mit folgendem Befehl eingestellt, dass im Header der HTTP-Antwort UTF-8 als Zeichensatz angegeben wird:

AddDefaultCharset UTF-8

MySQL

In der /etc/my.cnf

init-connect='SET NAMES utf8'

Bei jeder Verbindungsaufnahme (bspw. mysql_connect() via PHP) wird der Zeichensatz der ausgelieferten Daten damit auf UTF-8 geschaltet.

Selbstverständlich muss man aber immer noch aufpassen, in welchem Zeichensatz man Datenbank-Dumps exportiert und wieder einspielt …

Tags: , , , , ,
Labels: Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 11. Mai 2008

MySQL INSERTs und UPDATEs mit Subselects

Kürzlich durfte ich nachträglich zwei Datenbanktabelle normalisieren. Obwohl ich längst von den Subselect-Fähigkeiten von MySQL wusste, hatte ich es bis dato noch nie ausprobiert. Wie es sich herausgestellt hat, ist das Prozedere deutlich einfacher, als ich es mir erträumt hatte.

Rubriken neu in separater Tabelle

Die Tabelle daten enthält bspw. Adressen, die jeweils einer bestimmten Rubrik zugewiesen sind. Selbstverständlich kann man die Rubrik in dieselbe Tabelle hardcoden – doch deutlich hübscher ist es, die Rubrik in eine eigene Tabelle auszulagern und diese mittels eines Foreign Keys zu verknüpfen. Einer der Vorteile: Muss der Name einer Rubrik angepasst werden, geschieht dies an einem einzigen Ort, die Änderung wird aber gleich für alle Adressen übernommen.

Folgender Befehl nahm die hardcodierten Rubriken und fügte diese (jeweils einmal!) in die Tabelle rubriken ein:

INSERT INTO daten_rubriken
(rubrik)
SELECT DISTINCT(rubrik) FROM daten

Wichtig ist die SELECT ... Klausel – bis dahin handelt es sich beim SQL-Query um einen ganz normalen INSERT. DISTINCT bewirkt, dass der Rubrikennamen nur einmal ausgelesen wird (es können ja dutzende oder tausende Einträge dieselbe Rubrik haben).

Rubriken-IDs in Ursprungstabelle

Nachdem wir also nun die Rubriken in eine eigene Tabelle ausgelagert haben, möchten wir diese wieder mit der Ursprungstabelle verknüpfen. Hierzu verknüpfen wir die Textfelder der Ursprungs- mit der Rubriken-Tabelle und fügen in die Ursprungstabelle in ein neu erstelltes Feld die ID der Rubrik ein:

UPDATE daten d
SET d.`daten_rubriken-id` = (SELECT r.id FROM daten_rubriken r WHERE r.rubrik = s.rubrik)

Tags: , ,
Labels: Allgemein

1 Kommentar | neuen Kommentar verfassen

Mittwoch, 29. August 2007

Danke Hostpoint! (oder: MySQL Suchen-und-Ersetzen)

Dank dem Wechsel von PHP4 auf PHP5 bei meinem für Kunden bevorzugten Hoster musste ich bei einigen Web-Sites folgende Änderungen vornehmen:

UPDATE `smt_content`
SET source_de = REPLACE( source_de,  'PHP_SELF',  'ORIG_SCRIPT_NAME' )

Das Problem scheint daher zu rühren, dass PHP5 als CGI ausgeführt wird und einige Werte von $_SERVER nicht oder falsch zu setzen scheint. Mit ORIG_SCRIPT_NAME erhalte ich auf jeden Fall wieder den vom Web-Server ausgesehenen WWW-Pfad zum entsprechenden Script.

ACHTUNG

Natürlich erst, nachdem ich einen Dump der entsprechenden Tabelle gezogen hatte (ein Typo, und flutsch sind alle Seiteninhalte nach /dev/null unterwegs).

Nachtrag

Im Oktober 2007 wurde ein weiterer Wechsel nötig. Neu heisst die gesuchte Variable SCRIPT_NAME:

UPDATE `smt_content` SET source_de = REPLACE( source_de,  'PHP_SELF',  'SCRIPT_NAME' )

Tags: ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen