 |
| Hinweise |
Willkommen im TP-Hilfe-Forum!Dies ist ein Forum zu den Themen Photoshop, Dreamweaver, Flash, Selbständigkeit und mehr, in dem Du Hilfe, Anleitung oder eine Lösung zu Deinen Problemen erhältst. Aktuell bist Du in unseren Foren als Gast mit reinen Leserechten unterwegs. Wenn Du Dich registrierst, kannst Du eigene Themen verfassen, Deine Frage stellen und privat mit anderen TPlern kommunizieren. Weitere Foren werden zugänglich, und Du wirst – falls gewünscht – per Mail über neue Beiträge informiert. Die Registrierung ist schnell und kostenlos. Sollten bei der Registrierung Fragen auftauchen, reicht ein Klick in unsere Hilfe - Häufig gestellte Fragen oder eine kurze Mitteilung an das Support-Team. Viel Spaß bei Traum-Projekt.com |
03.01.2006, 10:10
|
#16
|
|
TP-Greis
Registriert seit: Aug 2002
Ort: Hochfranken
|
Zitat:
|
Zitat von DSB
Chief Senior Web Application Mainstream Framework Consultant Assistant of Incoming and Outgoing Sourcecode Developement
|
heißt das, Du hast schon jemand im Büro, der für dich Kaffee mitkocht? 
|
|
|
03.01.2006, 10:34
|
#17
|
|
TP-Veteran
Registriert seit: Mar 2005
Ort: Oyten
|
Dummerweise nicht.
Da sitzen nur 15 Leute, die sich solche Stellenbezeichnungen ausdenken und dann habe ich noch 4 Mann in der Werkstatt, die die Rahmen für die Visitenkarten zusammenschweißen.
Das sind topqualifizierte Leute, aber Kaffee kochen können die nicht.
Das muss ich selbst machen. 
|
|
|
03.01.2006, 10:48
|
#18
|
|
TP-Special Mod
Registriert seit: Feb 2005
Ort: Haan / NRW
|
|
|
|
04.03.2008, 13:36
|
#19
|
|
TP-Junior
Registriert seit: Mar 2008
|
sorry wenn ich das leidliche thema nochmal aufrolle, aber ich komme nicht mehr weiter. habe duzende foren durchsucht und ich bin bisher keinen schritt weiter gekommen.
zu meiner situation:
DB umzug auf neuen php5 server -> dabei umstellung auf UTF8
ich kann garantieren das:
1. neu DB inklusiver aller tabellen in UTF8 konvertiert/erstellt sind
2. die daten an sich ebenfalls in UTF8 vorliegen
3. die anbindung der DB aus der anwendung heraus auch auf UTF8 gestellt ist.
das hat aber zur folge das die darstellung der umlaute im frontend nur kraut und rüben ist.
stell ich die verbindung (SET NAMES ...) auf LATIN1, dann ist die darstellung korrekt.
phpmyadmin sagt mir (mit show variables) das alle charakter_sets korrekt auf UTF8 eingestellt sind, mit ausnahme von "character_set_server". das ist immer noch auf latin gestellt. ebenso ist die collation_database die callation_connection korrekt auf UTF8 eingestellt. "collation_server" allerdings wieder auf latin.
ich kann mir darauf keinen reim machen. kann es an den beiden werten liegen? ich habe eigentlich alles andere ausgeschlossen!?!
diese werte soll man ja (laut google suche) in der my.cnf setzen können. in meiner umgebung gibts keine "my.cnf". auf dem linux server liegen unter /usr/share/mysql/ mehrere verschiedene cnf's. ich kann nicht nachvollziehen welche davon benutzt wird.
wenn irgendwer noch eine idee hat, ich wäre wirklich sehr dankbar!
gruß
markus
Geändert von §_mo (04.03.2008 um 13:49 Uhr).
Grund: hab eine möglichkeit gefunden die cnf's zu editieren
|
|
|
04.03.2008, 15:49
|
#20
|
|
TP-Veteran
Registriert seit: Mar 2005
Ort: Oyten
|
Lies Dir das mal durch:
http://www.mysqldumper.de/board/viewtopic.php?t=2313
Wahrscheinlich hast Du bereits falsch kodierte Umlaute in der DB. Im Artikel findest Du ein Programm, welches das korrigieren kann.
|
|
|
05.03.2008, 11:42
|
#21
|
|
TP-Junior
Registriert seit: Mar 2008
|
ich hatte den guide schon vorher gelesen. hatte irgendwie gehofft das es an callation_server und character_set_server liegt
mit sqldump habe ich auch schon versucht einen dump zu erstellen, aber da bekomme ich immer einen socket error. keine ahnung woran das liegt. hab mich mit dem fehler (2002) auch durch-ge-googelt, ohne erfolg.
euer msqldumper läßt ich auch nicht in die gänge kriegen. es scheitert schon daran das ich der config.php keine anderen rechte zuweise kann. denke mal meine eigenen rechte reichen dafür nicht aus. und ich habe momentan keine möglichkeit das zu ändern (der verantwortliche ist nicht zugegen).
die anzeige der umlaute in myphpadmin ist auf jeden fall korrekt. und wenn ich den dump (den ich mit phpmyadmin erstellt habe) in einem editor öffne dann werden die umlaute auch richtig angezeigt. auch mit utf8. ich werd noch ein bisschen (umständlich) rumprobieren. ich klammere mich dabei an den ansatz, das es an dem falschen format der daten liegt und nicht an was anderem.
gruß
markus
NACHTRAG:
die darstellungsfehler entsprechen denen aus der guide-beschreibung für das szenario: utf8-daten ziehen nach latin-DB um. also die ersetzung des einen utf8 zeichens durch 2 (äöü...). das sagt mir doch jetzt eigentlich, das der sql server das problem ist, oder? er scheint irgendwie/irgendwo latin zu erwarten. die DB und alle tabellen sind definitiv in utf8 erstellt und werden mir auch so angezeigt. beim import des dumps gebe ich an, das ich daten im utf8 format (dropdown menü) importiere. also wo kracht das denn bitte?!
__________________
zu blöde den eigenen nick richtig einzugeben ... §=$ !
Geändert von §_mo (05.03.2008 um 11:56 Uhr).
|
|
|
05.03.2008, 12:14
|
#22
|
|
TP-Special Mod
Registriert seit: Feb 2005
Ort: Haan / NRW
|
der server ist nicht das problem, es ist immer der user 
wenn die Daten mit latin1 kodiert wurden, dann sind sie auch mit latin1 gespeichert. Das hat nix mit den Einstellungen zu tun. Man kann nicht einfach einen Hebel umlegen und alle Daten sind plötzlich utf8, also müssen die Daten konvertiert werden.
|
|
|
05.03.2008, 12:38
|
#23
|
|
TP-Junior
Registriert seit: Mar 2008
|
die alte datenbank inklusive die alte phpmyadmin version wurden von irgend einer externen firma lange vor meiner zeit verwaltet. keine ahnung wie, aber sie haben in phpmyadmin beim export die funktion freigeschaltet/implementiert, das man auch beim beim Export die kollation angeben kann in der die daten raus sollen. habe versucht nachzuvollziehen wie sie das gemacht haben, ohne erfolg (ein serverseitiges uploadverzeichnis für dumps hab ich ja auch hinbekommen).
jedenfalls kann ich beim export aus der alten DB bereits utf8 angeben. und das die daten dann tatsächlich in utf8 vorliegen, dafür habe ich, denke ich, bereits argumente geliefert.
also nochmal: ich bin zu 99% sicher das die daten tatsächlich in utf8 vorliegen!
ich denke der import in die neue DB ist das problem (mysql client 5.0.51 + phpmyadmin 2.11.0).
__________________
zu blöde den eigenen nick richtig einzugeben ... §=$ !
Geändert von §_mo (05.03.2008 um 12:55 Uhr).
|
|
|
05.03.2008, 16:29
|
#24
|
|
TP-Veteran
Registriert seit: Mar 2005
Ort: Oyten
|
Ich frage mich ernsthaft, wie Du anständig debuggen willst, wenn Du noch nicht einmal ein simples PHP-Skript auf dem Server ans Laufen bekommst. Deine Überzeugung alles richtig gemacht zu haben in allen Ehren. Ich habe aber genug Probleme beim Import und auch bei der Anzeige von Daten mit PhpMyAdmin gehabt, um zu wissen, dass das nicht immer gelingt, auch wenn man alles korrekt angibt.
Wie die Zusammenhänge wirklich sind kann zumindest ich nur dann einschätzen, wenn MSD ab Version 1.22 läuft. Da bin ich 100%ig sicher, dass die Daten korrekt im SQLBrowser angezeigt werden und auch genau so in der DB vorliegen. Allen anderen Programmen traue ich keinen Zentimeter mehr über den Weg. Sogar das vB macht in Bezug auf utf8-Umstellung konzeptlosen Blödsinn (ich habe mir eine Lizenz gekauft, wollte auf utf8 umstellen und war bei Ansicht des Codes entsetzt!).
Gewissheit also mit korrekter Installation von MySQLDumper ab Version 1.22 . 
|
|
|
|
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
|
|
|
| Themen-Optionen |
Thema durchsuchen |
|
|
|
| Thema bewerten |
|
|
Forumregeln
|
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
HTML-Code ist aus.
|
|
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:37 Uhr.
|
 |