SELFPHP: Version 5.8.2 Befehlsreferenz - Tutorial – Kochbuch – Forum für PHP Einsteiger und professionelle Entwickler

SELFPHP


Professional CronJob-Service

Suche



CronJob-Service    
bei SELFPHP mit ...



 + minütlichen Aufrufen
 + eigenem Crontab Eintrag
 + unbegrenzten CronJobs
 + Statistiken
 + Beispielaufrufen
 + Control-Bereich

Führen Sie mit den CronJobs von SELFPHP zeitgesteuert Programme auf Ihrem Server aus. Weitere Infos



:: Buchempfehlung ::

PHP 5.3 & MySQL 5.1

PHP 5.3 & MySQL 5.1 zur Buchempfehlung
 

:: Anbieterverzeichnis ::

Globale Branchen

Informieren Sie sich über ausgewählte Unternehmen im Anbieterverzeichnis von SELFPHP  

 

:: Newsletter ::

Abonnieren Sie hier den kostenlosen SELFPHP Newsletter!

Vorname: 
Name:
E-Mail:
 
 

Zurück   PHP Forum > SELFPHP > MySQLi/PDO/(MySQL)
Hilfe Community Kalender Heutige Beiträge Suchen

MySQLi/PDO/(MySQL) Anfänger, Fortgeschrittene oder Experten können hier Fragen und Probleme rund um MySQLi/PDO/(MySQL) diskutieren

Antwort
 
Themen-Optionen Ansicht
  #1  
Alt 03.06.2009, 18:58:31
Benutzerbild von CeBe
CeBe CeBe ist offline
Anfänger
 
Registriert seit: Oct 2008
Ort: Freden
Alter: 35
Beiträge: 37
CeBe eine Nachricht über ICQ schicken CeBe eine Nachricht über Skype™ schicken
utf8_unicode_ci und PREPARE Statements

Moin Leute!

auf MySQL 5.4 und 5.1.34 getestet.

Die Problematik verfolgt mich nun schon mehrere Wochen. Das Problem tritt, soweit ich es bisher eingrenzen konnte mit Prozeduren auf, die PREPARE-Statements verwenden, ich vermute allerdings, dass es noch irgendwo im Server eine versteckte Config übersehen hab.
Der SQL-Query wird in folgender Reihenfolge ausgeführt:
Code:
SET NAMES 'utf8' COLLATE 'utf8_unicode_ci';

USE testdb;

CALL proc_statistic_list_activities_select ( '5' , '0000-00-00 00:00:00' , '2009-06-03 17:02:20' , 5 );
dieser wirft folgenden Error:

ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,COERCIBLE) and (utf8_unicode_ci,COERCIBLE) for operation '<>'

Meine Config:
Code:
mysql> SHOW VARIABLES LIKE 'character_set%';
+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | utf8                       | 
| character_set_connection | utf8                       | 
| character_set_database   | utf8                       | 
| character_set_filesystem | binary                     | 
| character_set_results    | utf8                       | 
| character_set_server     | utf8                       | 
| character_set_system     | utf8                       | 
| character_sets_dir       | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+
8 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation%';
+----------------------+-----------------+
| Variable_name        | Value           |
+----------------------+-----------------+
| collation_connection | utf8_unicode_ci | 
| collation_database   | utf8_unicode_ci | 
| collation_server     | utf8_unicode_ci | 
+----------------------+-----------------+
3 rows in set (0.00 sec)
Auszug aus /etc/mysql/my.cnf
Code:
[mysqld]

[...]

# encoding settings 

default-character-set=utf8
default-collation=utf8_unicode_ci
character-set-server=utf8
collation-server=utf8_unicode_ci 
character-set-server=utf8
collation-server=utf8_unicode_ci
Obwohl in der my.cnf die default-collation=utf8_unicode_ci gesetzt ist, findet sich in der Tabelle information_schema.COLLATIONS ein Eintrag bei Default auf utf8_general_ci und alle Tabellen in der Datenbank mysql und information_schema sind auf utf8_unicode_ci gesetzt.

Code:
mysql> SELECT * FROM information_schema.COLLATIONS;
+--------------------+--------------------+-----+------------+-------------+---------+
| COLLATION_NAME     | CHARACTER_SET_NAME | ID  | IS_DEFAULT | IS_COMPILED | SORTLEN |
+--------------------+--------------------+-----+------------+-------------+---------+
[...]
| utf8_general_ci    | utf8               |  33 | Yes        | Yes         |       1 | 
| utf8_bin           | utf8               |  83 |            | Yes         |       1 | 
| utf8_unicode_ci    | utf8               | 192 |            | Yes         |       8 | 
[...]
| binary             | binary             |  63 | Yes        | Yes         |       1 | 
+--------------------+--------------------+-----+------------+-------------+---------+
30 rows in set (0.00 sec)
Wenn noch Infos fehlen, einfach nachfragen!

Bin für jeden Ansatz dankbar!

MfG
Carsten
__________________
Mit Zitat antworten
  #2  
Alt 03.06.2009, 23:38:55
Damir Damir ist offline
Administrator
 
Registriert seit: Jan 2002
Ort: Köln
Alter: 53
Beiträge: 1.276
AW: utf8_unicode_ci und PREPARE Statements

Hallo Carsten,

hier sollte es eigentlich erklärt werden - bin allerdings auch nur kurz rüber geflogen:

http://dev.mysql.com/doc/refman/5.1/...epertoire.html

Damir
__________________
Qozido - Die Bilderverwaltung mit Logbuch für Taucher und Schnorchler.

www.qozido.de
Mit Zitat antworten
  #3  
Alt 04.06.2009, 01:15:25
Benutzerbild von CeBe
CeBe CeBe ist offline
Anfänger
 
Registriert seit: Oct 2008
Ort: Freden
Alter: 35
Beiträge: 37
CeBe eine Nachricht über ICQ schicken CeBe eine Nachricht über Skype™ schicken
AW: utf8_unicode_ci und PREPARE Statements

Zitat:
Zitat von Damir Beitrag anzeigen
hier sollte es eigentlich erklärt werden - bin allerdings auch nur kurz rüber geflogen:

http://dev.mysql.com/doc/refman/5.1/...epertoire.html
Danke für den Link, das hilft mir aber nicht weiter...

Es geht ja darum, dass ich gerade das nicht brauche, da ich NUR mit utf8_unicode_ci arbeite, was auch in allen Config-Variablen steht. Somit dürfte eigentlich kein utf8_general_ci auftauchen...

MfG
Carsten
__________________
Mit Zitat antworten
  #4  
Alt 04.06.2009, 02:30:06
Benutzerbild von CeBe
CeBe CeBe ist offline
Anfänger
 
Registriert seit: Oct 2008
Ort: Freden
Alter: 35
Beiträge: 37
CeBe eine Nachricht über ICQ schicken CeBe eine Nachricht über Skype™ schicken
AW: utf8_unicode_ci und PREPARE Statements

Bin dem Problem ein bisschen näher gekommen...
Wenn ich eine Funktion anlege:
Code:
DELIMITER //

CREATE FUNCTION `func_select_statistic_module_name_statistic_module_id`(
  `v_statistic_module_id` int
) RETURNS varchar(50)
     READS SQL DATA
BEGIN

[...]

   RETURN v_name;

END
//
verändert MySQL die Funktion folgendermaßen: (rot)

Code:
SHOW CREATE FUNCTION func_select_statistic_module_name_statistic_module_id;

CREATE FUNCTION `func_select_statistic_module_name_statistic_module_id`(
  `v_statistic_module_id` int
) RETURNS varchar(50) CHARSET utf8
    READS SQL DATA
BEGIN

[...]

     RETURN v_name;
END
Was allerdings nach MySQL-Bug 24690 nicht wie gewünscht funktioniert und erst in Version 6 gefixt sein wird...

Bin jetzt zu müde um über nen Workaround nachzudenken.
Ginge so in die Richtung Default Collation für utf8 in utf8_unicode_ci ändern statt utf8_general_ci. Oder die Rückgabe der Funktion nach unicode zu convertieren.
Werde da morgen weiter denken, vielleicht hat ja jemand noch ne interessante Idee :-)

MfG
Carsten
__________________
Mit Zitat antworten
  #5  
Alt 04.06.2009, 07:56:54
Damir Damir ist offline
Administrator
 
Registriert seit: Jan 2002
Ort: Köln
Alter: 53
Beiträge: 1.276
AW: utf8_unicode_ci und PREPARE Statements

Zitat:
Zitat von CeBe Beitrag anzeigen
Obwohl in der my.cnf die default-collation=utf8_unicode_ci gesetzt ist, findet sich in der Tabelle information_schema.COLLATIONS ein Eintrag bei Default auf utf8_general_ci und alle Tabellen in der Datenbank mysql und information_schema sind auf utf8_unicode_ci gesetzt.
Hmm, ich vermute mal das MySQL schon mit utf8_general_ci kompiliert wurde und daher der Wert so automatisch gestezt ist....

Wegen Deinem Problem - kann es sein, das Du in nachhinein alles auf UTF8 umgestellt hast oder hast du von Grund auf alles auf UTF8 eingestellt und erst dann die Daten eingefügt? Das Problem kommt eigentlich immer dann auf wenn man den "Pfad der Tugend" ;-) verlässt - spricht, man darf die Kette nicht verlassen und muss wirklich alles (von der Verbindung zur DB bis zum auslesen der Tabelle mit UTF8 machen).

Vielleicht würde hier auch http://de2.php.net/manual/de/function.utf8-encode.php und http://de2.php.net/manual/de/function.utf8-decode.php weiter helfen...

Oft reicht es schon aus wenn man einfach alle Daten expotiert, eine komplette neue Tabelle erstellt, die komplett auf UTF8 einstellt und dann die Daten richtig wieder in die DB einfliessen lässt...

Damir
__________________
Qozido - Die Bilderverwaltung mit Logbuch für Taucher und Schnorchler.

www.qozido.de
Mit Zitat antworten
  #6  
Alt 04.06.2009, 12:52:37
Benutzerbild von CeBe
CeBe CeBe ist offline
Anfänger
 
Registriert seit: Oct 2008
Ort: Freden
Alter: 35
Beiträge: 37
CeBe eine Nachricht über ICQ schicken CeBe eine Nachricht über Skype™ schicken
AW: utf8_unicode_ci und PREPARE Statements

Zitat:
Zitat von Damir Beitrag anzeigen
Hmm, ich vermute mal das MySQL schon mit utf8_general_ci kompiliert wurde und daher der Wert so automatisch gestezt ist....
leider nein:
Code:
./configure --with-charset=utf8 --with-collation=utf8_unicode_ci --with-unix-socket-path=/var/run/mysqld/mysqld.sock --with-tcp-port=3306 --with-mysqld-user=mysql --without-bench --without-debug --prefix=/usr/ --sysconfdir=/etc/
Zitat:
Zitat von Damir Beitrag anzeigen
Wegen Deinem Problem - kann es sein, das Du in nachhinein alles auf UTF8 umgestellt hast oder hast du von Grund auf alles auf UTF8 eingestellt und erst dann die Daten eingefügt? Das Problem kommt eigentlich immer dann auf wenn man den "Pfad der Tugend" ;-) verlässt - spricht, man darf die Kette nicht verlassen und muss wirklich alles (von der Verbindung zur DB bis zum auslesen der Tabelle mit UTF8 machen).
Alle Felder, alle Tabellen, meine Datenbank (information_schema allerdings nicht), die Verbindung sind alle UTF8, im PHP nutze ich nur die Multi-Byte-String funktionen und die Ausgabe ist ebenfalls UTF8.

Da liegt aber nicht das Problem, habe das ja schon soweit lokalisiert, dass es mit dem o.g. Bug zusammen hängt.

Zitat:
Zitat von Damir Beitrag anzeigen
Oft reicht es schon aus wenn man einfach alle Daten expotiert, eine komplette neue Tabelle erstellt, die komplett auf UTF8 einstellt und dann die Daten richtig wieder in die DB einfliessen lässt...
Habe sogar schon nen neuen komplett frischen Server aufgesetzt ;-)

Das Problem ist, dass wenn ich in der Funktion sage:
CHARSET utf8 ohne eine COLLATION anzugeben nimmt er per Default utf8_general_ci, weil das die Standard-Collation für utf8 ist bei MySQL.
Eine COLLATION kann ich, wie im Bug oben erklärt ist nicht angeben, da das erst in Version 6 gefixt wird und Version 5.4 sogar noch Beta ist.
Bin nun auf der Suche nach einer Möglichkeit das umzustellen, dass er utf8_unicode_ci als default hat oder noch besser gar kein utf8_general_ci mehr kennt...

MfG
Carsten
__________________
Mit Zitat antworten
  #7  
Alt 05.06.2009, 11:40:15
Benutzerbild von CeBe
CeBe CeBe ist offline
Anfänger
 
Registriert seit: Oct 2008
Ort: Freden
Alter: 35
Beiträge: 37
CeBe eine Nachricht über ICQ schicken CeBe eine Nachricht über Skype™ schicken
AW: utf8_unicode_ci und PREPARE Statements

Yeah! Ich hab nen Workaround :-)

Die Lösung heißt CAST.

Code:
CAST(func_my_function(1, 'test') AS CHAR CHARACTER SET utf8) COLLATE utf8_unicode_ci;
3 volle Arbeitstage wegen so nem sch... Bug :-D und es funzt :-)

Da nochmal der Bug: http://bugs.mysql.com/bug.php?id=24690
__________________

Geändert von CeBe (05.06.2009 um 11:42:15 Uhr) Grund: link
Mit Zitat antworten
  #8  
Alt 05.06.2009, 11:42:32
Damir Damir ist offline
Administrator
 
Registriert seit: Jan 2002
Ort: Köln
Alter: 53
Beiträge: 1.276
AW: utf8_unicode_ci und PREPARE Statements

Kenne ich zur Genüge diese Suche nach etwas ...;-)

Aber ist doch gut das es jetzt klappt und das Du den Fehler selber gefunden hast;-)

Damir
__________________
Qozido - Die Bilderverwaltung mit Logbuch für Taucher und Schnorchler.

www.qozido.de
Mit Zitat antworten
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind aus.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Abarbeitung von If Statements crowl PHP Grundlagen 4 27.02.2004 16:54:10


Alle Zeitangaben in WEZ +2. Es ist jetzt 21:52:27 Uhr.


Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.


© 2001-2024 E-Mail SELFPHP OHG, info@selfphp.deImpressumKontakt