engelhuber.de //blog

Gehirnfürze aus der Sicht eines Nerds

PHP/PDO/MSSQL und Umlaute in Spaltennamen und Strings

| 4 Kommentare

php_pdoSo, das hat mich nun echt Nerven und einige Stunden Zeit gekostet, aber ich wollte einfach dahinter steigen.
Ziel war es ein simples SQL Update Query mittels PHP auf einer MSSQL Datenbank auszuführen. Das Problem dabei, ein paar der Spalten beinhalten Umlaute.

Da ich bisher noch nie mit PHP auf MSSQL zugegriffen habe sondern nur auf MySQL, war mein erster Versuch die Funktion mssql_query().
Das funktioniert so weit auch gut, bis die Umlaute in den Spaltennamen ins Spiel kommen.
Die Meldung sieht so aus: Warning: mssql_query() [function.mssql-query]: message: Ungltiger Spaltenname ‚Spalte mit Ümlaut‘. (severity 16) in index.php on line 79
Komisch dass er den Spaltennamen in der Fehlermeldung korrekt ausgibt. Im Management Studio funktioniert die Abfrage ohne Probleme.

Ein Bekannter hat mir dann den Tipp gegeben doch mal die PDO Treiber für MSSQL zu probieren.
Der Treiber wird als Erweiterung in der php.ini geladen. Gesagt getan.
Mit dem Treiber gab es allerdings schon beim Verbindungsaufbau mit dem Server einen Fehler: PHP Fatal error: Uncaught exception ‚PDOException‘ with message ‚SQLSTATE[IMSSP]: This extension requires the Microsoft SQL Server 2012 Native Client ODBC Driver to communicate with SQL Server. Access the following URL to download the Microsoft SQL Server 2012 Native Client ODBC driver for x86: http://go.microsoft.com/fwlink/?LinkId=163712′ in pdo.php:3 Stack trace: #0 pdo.php(3): PDO->__construct(’sqlsrv:Server=1…‘, ‚xx‘, ‚yy‘) #1 {main} thrown in pdo.php on line 3  

Für den Treiber werden also die SQL Native Treiber 2012 benötigt. Blöd dass diese als Systemvoraussetzung Windows Server 2008 haben und mein Webserver auf einem Windows 2003 Server läuft. 😉

Nach weiterer Recherche bin ich dann auf einen inoffiziellen PDO MSSQL Treiber gestoßen (danke Rob) der diese Überprüfung umgeht.
Mit diesem konnte ich nun die Verbindung aufbauen, aber es geht weiter 🙂

Fatal error: Uncaught exception ‚PDOException‘ with message ‚SQLSTATE[42S22]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Ungültiger Spaltenname ‚Spalte mit mlaut‘.‘ in pdo.php:25 Stack trace: #0 pdo.php(25): PDO->exec(‚update …‘) #1 {main} thrown in pdo.php on line 25

Nun fehlt der Umlaut der Spalte bereits bei der Fehlermeldung. Auch nach einigem hin und her mit Zeichensätzen etc. bin ich leider nicht weiter gekommen.
Schließlich habe ich es mal mit ODBC versucht. Die Erweiterung wird ebenfalls über die php.ini eingebunden (extension=php_pdo_odbc.dll) und mit der Funktion
$c = new PDO(„odbc:ODBC_Verbindung“, „user“, „pass“);“ aufgerufen.

Siehe da, es funktioniert. Umlaute in Feldwerten ebenfalls. Warum nicht gleich so?? 🙂

Autor: Engelhuber

Wenn dir der Post hilfreich war bzw. er dir gefallen hat, würde ich mich über ein Kommentar freuen. Natürlich ist auch negative Kritik gerne gesehen ;) Du findest mich auch auf Google+...

4 Kommentare

  1. Haha, bin grad über den Artikel gestolpert und dachte noch so „Da haben wir doch drüber gesprochen“. 😉
    Allerdings ist mein Problem ein anderes. Ich habe ein Projekt das per ODBC angebunden ist. Hier werden bei der Ausgabe in PHP die Umlaute korrekt dargestellt. Auf einem anderen System wo ich den SQL Treiber nutze muss ich die erst mit utf8_decode „behandeln“, was natürlich blöd ist, da man so zwei verschiedene Codes bekommt…suche gerade noch eine Möglichkeit, die Umlautdarstellung korrekt ohne den Befehl hinzubekommen…

  2. Hehe, genau. Du warst der „Bekannte“ 😉
    Hmm, worin unterscheiden sich denn die Systeme?
    PHP Version? OS Version? ODBC Treiber Version?
    Dürfte aber doch auch nichts ausmachen wenn du auf beiden Systemen utf8_decode verwendest oder?

  3. Das eine ist wie gesagt per ODBC Treiber für PHP angebunden, das andere direkt mit dem SQL Treiber für PHP.
    Bei der ODBC Variante muss ich die INSERTs und UPDATEs mit utf8_decode machen, sonst steht murks in der DB.
    Bei der SQL Treiber Variante muss ich utf8_decode beim echo machen.
    Beides mal beides, gibt auch murks. Geht nur in dieser Variante.

    Um es auf den SQL Treiber umzustellen müsste ich beim Kunden jetzt also alle Ausgaben mit utf8_decode versehen…und das wäre ein ziemlicher Aufwand…

  4. Achso, ja klar. Und was spricht dagegen beide auf ODBC laufen zu lassen?

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.