nicht angemeldet
Mysql Client
moin,
wo finde ich den bitte auf der mysql webseite einen mysql client, ich sehe im download bereich nur odbc connectoren, datenbank, modeler....
Ilja
-
Hi!
wo finde ich den bitte auf der mysql webseite einen mysql client, ich sehe im download bereich nur odbc connectoren, datenbank, modeler....
Einfache Kommandozeilen-Clients sind im Grundpaket enthalten. Ansonsten gibts die MySQL Workbench.
Lo!
-
Hallo Ilja,
wo finde ich den bitte auf der mysql webseite einen mysql client, ich sehe im download bereich nur odbc connectoren, datenbank, modeler....
das MySQL-GUI-Bundle hat das Ende seiner Lebenszeit erreicht. Es wurde abgelöst durch die MySQL-Workbench. Du benötigst eine 5.2er (Beta-)Version, um einen SQL-Client zu haben. In der 5.1er-Version (die derzeit den Status GA hat) ist kein SQL-Client enthalten.
Freundliche Grüße
Vinzenz
-
moin,
Du benötigst eine 5.2er (Beta-)Version, um einen SQL-Client zu haben. In der 5.1er-Version (die derzeit den Status GA hat) ist kein SQL-Client enthalten.
habe mir schon einen wolf nach einem mysql client gesucht, muss eine entfernte mysql datenbank erreichen. vielen dank euch beiden...
Ilja
-
inzwischen klappt es mit der verbindung, aber ich scheine ein problem mit der zeichencodierung zu haben. wie gesagt ich benutzt die workbench, zeichensatz der tabellen ist UTF-8 und Collation utf8_general_ci. gibt es eine möglichkeit an der workbench dies bezüglich eine einstellung vorzunehmen ?
Ilja
-
Hi!
inzwischen klappt es mit der verbindung, aber ich scheine ein problem mit der zeichencodierung zu haben. wie gesagt ich benutzt die workbench, zeichensatz der tabellen ist UTF-8 und Collation utf8_general_ci. gibt es eine möglichkeit an der workbench dies bezüglich eine einstellung vorzunehmen ?
Wie schon so oft gesagt, ist die Kodierung der Felder(!) nur für den ablegbaren Inhalt interessant (und die Kollation bei Kodierungsproblemen egal). Das was zwischen Server und Client gesprochen wird, ist die Verbindungskodierung. Wenn diese anders ist als die Feldkodierungen, nimmt MySQL selbständig Umkodierungen vor.
Die MySQL Workbench (grad eben frisch installiert und im Query-Log des Servers nachgesehen) handelt nach dem Verbindungsaufbau UTF-8 als Verbindungskodierung aus. Wenn du falsche Daten siehst, sind diese aller Wahrscheinlichkeit nach schon falsch abgelegt. Wurde denn beim Verwenden von anderen Programmen darauf geachtet, eine Verbindungskodierung explizit auszuhandeln?
Lo!
-
moin dedlfix,
Die MySQL Workbench (grad eben frisch installiert und im Query-Log des Servers nachgesehen) handelt nach dem Verbindungsaufbau UTF-8 als Verbindungskodierung aus. Wenn du falsche Daten siehst, sind diese aller Wahrscheinlichkeit nach schon falsch abgelegt.
das war auch meine erste vermutung, dass die Daten schon dort falsch gespeichert sind. ich muss der sache aber noch mal nachgehen.
Wurde denn beim Verwenden von anderen Programmen darauf geachtet, eine Verbindungskodierung explizit auszuhandeln?
ich habe für meine oracle datenbank, genauer gesagt für den "datenbank link" eine odbc verbindung eingerichtet und dort explizit UTF-8 angegeben. die gleichen probleme mit den sonderzeichen wie mit der workbench. allerdings kämpfe ich dort noch mit ganz anderen problemen rum, insofern wollte ich erst einmal nur von der workbench ausgehen.
Ilja
-
noch mal als zusatz, man hat mir einen link für eine php webseite bereit gestellt, Kodierung in UTF-8 und dort werden die sonderzeichen korrekt dargestellt. wenn die daten in UTF-8 in der datenbank abgespeichert wurden und auch die workbench mit UTF-8 kodiert, woran könnte es dann liegen ?
Ilja
-
Hi!
noch mal als zusatz, man hat mir einen link für eine php webseite bereit gestellt, Kodierung in UTF-8 und dort werden die sonderzeichen korrekt dargestellt. wenn die daten in UTF-8 in der datenbank abgespeichert wurden und auch die workbench mit UTF-8 kodiert, woran könnte es dann liegen ?
Frag mal den Webseitenbetreuer, ob er die Funktion mysql_set_charset() oder mysqli_set_charset() kennt und verwendet hat oder ersatzweise ein SET-NAMES-Statement nach dem Connect abschickt.
Kann diese Seite die Daten auch sortiert abfragen? Sortiert sie Umlaute richtig ein?
Lo!
-
-
Hi!
Die MySQL Workbench (grad eben frisch installiert und im Query-Log des Servers nachgesehen) handelt nach dem Verbindungsaufbau UTF-8 als Verbindungskodierung aus. Wenn du falsche Daten siehst, sind diese aller Wahrscheinlichkeit nach schon falsch abgelegt.
das war auch meine erste vermutung, dass die Daten schon dort falsch gespeichert sind. ich muss der sache aber noch mal nachgehen.Zeig mal, was du bei einem Umlaut in der Workbench siehst. Und frag von einem Wert mit Sonderzeichen drin LENGTH() und CHARACTER_LENGTH() ab. Das eine muss die Anzahl der Bytes liefern (also bei einem String mit n Zeichen inklusive einem Umlaut: n+1), das andere die Anzahl der Zeichen (also n). Wenn du n+3 und n+1 erhältst, hat man zwar UTF-8-Daten gesendet aber MySQL ging von Latin1 aus. MySQL wertet dann jedes UTF-8-Byte als ein Latin1-Zeichen, kodiert das zum Speichern gemäß Feldkodierung nach UTF-8 um. Beim Abfragen macht es daraus wieder Latin1 und übergibt es dem Client, woraufhin dieser davon ausgeht, die Bytes seien UTF-8. Das geht zunächst aus Client-Sicht problemlos, solange man immer mindestens n+ü Zeichen Platz im Feld hat und nicht Sortieren will (n=insgesamte Anzahl der Zeichen im Wert; ü=Anzahl der UTF-8-Zeichen aus dem Bereich U0080..U07FF).
Wurde denn beim Verwenden von anderen Programmen darauf geachtet, eine Verbindungskodierung explizit auszuhandeln?
ich habe für meine oracle datenbank, genauer gesagt für den "datenbank link" eine odbc verbindung eingerichtet und dort explizit UTF-8 angegeben. die gleichen probleme mit den sonderzeichen wie mit der workbench. allerdings kämpfe ich dort noch mit ganz anderen problemen rum, insofern wollte ich erst einmal nur von der workbench ausgehen.Oracle interessiert hier nicht, sondern die anderen Programme, die Daten in die MySQL-Tabellen schreiben, die du workbenchen willst. Übrigens müsste auch der phpMyAdmin das gleiche Problem bekommen, denn auch der handelt ordnungsgemäß eine Verbindungskodierung aus und ist auf korrekt gespeicherte Daten angewiesen.
Lo!
-
moin,
Zeig mal, was du bei einem Umlaut in der Workbench siehst. Und frag von einem Wert mit Sonderzeichen drin LENGTH() und CHARACTER_LENGTH() ab. Das eine muss die Anzahl der Bytes liefern (also bei einem String mit n Zeichen inklusive einem Umlaut: n+1), das andere die Anzahl der Zeichen (also n).
dsa ist der string, den ich mit der abfrage über die workbench sehe: "Pöhlitz". und ich bekomme daür bei LENGTH 11, bzw. bei character_LENGTH 8 zurück, so wie du es vermutet hast.
Wenn du n+3 und n+1 erhältst, hat man zwar UTF-8-Daten gesendet aber MySQL ging von Latin1 aus. MySQL wertet dann jedes UTF-8-Byte als ein Latin1-Zeichen, kodiert das zum Speichern gemäß Feldkodierung nach UTF-8 um.
das würde bedeuten, die daten sind schon falsch in die Datenbank gekommen, was meine verfälschten sonderzeichen erklärt.
Beim Abfragen macht es daraus wieder Latin1 und übergibt es dem Client, woraufhin dieser davon ausgeht, die Bytes seien UTF-8.
gut, das geht dann aber nur in dieser gesonderten konstellation, mein workbench client arbeitet ja mit utf-8. du meinst dadurch fällt es den anderen nicht auf, dass die codierung falsch ist ?
Oracle interessiert hier nicht, sondern die anderen Programme, die Daten in die MySQL-Tabellen schreiben, die du workbenchen willst.
ich schreibe gar keine daten rein, ich kann/solll die daten nur auslesen. das mache ich dann am ende über oracle, aber ich will zum besseren vergleich das auch parallel mit der workbench machen. insofern habe ich keinen einfluss auf die programme, die daten in die mysql datenbank schreiben.
Ilja
-
Hi!
das würde bedeuten, die daten sind schon falsch in die Datenbank gekommen, was meine verfälschten sonderzeichen erklärt.
Ja.
Beim Abfragen macht es daraus wieder Latin1 und übergibt es dem Client, woraufhin dieser davon ausgeht, die Bytes seien UTF-8.
gut, das geht dann aber nur in dieser gesonderten konstellation, mein workbench client arbeitet ja mit utf-8. du meinst dadurch fällt es den anderen nicht auf, dass die codierung falsch ist ?
(Deine) Workbench handelt im Gegensatz zu den anderen Pappnasen explizit eine Verbindungskodierung aus. Es nützt dir nun nichts, wenn es irgendwo generell auf Latin1 umzukonfigurieren wäre, denn dann ginge die Workbench sicherlich auch davon aus, dass es nun Latin1-Zeichen gäbe, was im Ergebnis nichts ändert. Aber, Trick 17: SET NAMES latin1; SELECT ...; So wie es aussieht, wertet die Workbench das SET NAMES nicht aus. Damit erreichst du nun, dass der MySQL-Server aus der doppelten UTF-8-Kodierung der Felddaten nun noch eine einfache macht, weil es denkt, es solle nun Latin1 liefern. Die Workbench hingegen geht weiterhin davon aus, UTF-8 zu bekommen, und so stimmt das ja auch. Damit hast du nun den gleichen Fehler beim Abfragen wie die fehlerhaften Programme der anderen.
ich schreibe gar keine daten rein, ich kann/solll die daten nur auslesen. das mache ich dann am ende über oracle, aber ich will zum besseren vergleich das auch parallel mit der workbench machen.
Das heißt, Oracle fragt über eine ODBC-Verbindung Daten aus MySQL ab. Dann musst du Latin1 als Verbindungskodierung konfigurieren oder SET NAMES latin1; als erstes Statement senden und dann UTF-8-Daten erwarten.
Lo!
-
moin,
Das heißt, Oracle fragt über eine ODBC-Verbindung Daten aus MySQL ab. Dann musst du Latin1 als Verbindungskodierung konfigurieren oder SET NAMES latin1; als erstes Statement senden und dann UTF-8-Daten erwarten.
das ist noch nicht ganz so trivial, ich habe eine oracle express version auf meinem arbeitsrechner installiert, um den Datenbank Link erst mal zu testen. mein betriebsstem ist aber vista 64 bit und oracle stellt dafür keine entsprechenden programme zur verfügung, nur für die 32 bit version. insofern kämpfe ich ein wenig an zwei fronten. deswegen will ich auch die workbench zum gegenvergleich ranziehen und da kann ich dann probleme mit sonderzeichen nicht gebrauchen. hinzu kommt, dass wenn ich den odbc treiber expizit mit latin1 angeben, oracle probleme bekommt, varchar spalten werden kann nicht mehr dargestellt, INT spalten falsch. liegt wohl auch an der kodierung.
Ilja
-
Hi!
deswegen will ich auch die workbench zum gegenvergleich ranziehen und da kann ich dann probleme mit sonderzeichen nicht gebrauchen.
Garbage in - Garbage out. Besser wäre natürlich, wenn die Verursacher ihren Fehler einsehen, ihn beseitigten und die Daten korrigierten.
hinzu kommt, dass wenn ich den odbc treiber expizit mit latin1 angeben, oracle probleme bekommt, varchar spalten werden kann nicht mehr dargestellt, INT spalten falsch. liegt wohl auch an der kodierung.
Auf INT darf das keinen Einfluss haben. Und wenn du auf Latin1 umstellst, dann darf das Oracle davon nichts wissen, es muss von UTF-8 ausgehen. Wenn es sich durch Konfiguration des ODBC-Treibers beeinflussen lässt, dann hilft nur ein SET-NAMES-Statement - gegebenenfalls vor jedem Statement, falls der ODBC-Treiber die Verbindung zwischenzeitlich abbaut - und hoffen, dass der ODBC-Treiber nicht mitliest.
Alles Folgegefrickel, das nicht sein müsste, wenn man gleich richtig angefangen hätte.
Lo!
-
moin,
Alles Folgegefrickel, das nicht sein müsste, wenn man gleich richtig angefangen hätte.
das sehe ich auch so, ich probiere gerade das mit denen abzusprechen, allerdings sitzen die nicht in europa, also "feindesland" ;-) vielen dank dedlfix, dass du meine vermutung dingfest machen konntest.
Ilja
-
moin,
Auf INT darf das keinen Einfluss haben.
noch mal als info für dich, ich habe noch ein wenig recherchiert, es handelt sich bei dem problem um einen oracle bug, der erst in den späteren versionen korrigiert wurde. mal schauen, was ich da mache. aber es sind tatsächlich zwei verschiedene probleme, die da auf mich zukommen, das eine ist die codierung, das andere der oracle bug. das arbeitsleben wäre ja auch nicht schön, wenn es einfach wäre....
Ilja
-
-
-
-
-
-
-
-
-
-