MySQL wo default-character-set definieren?

[Tom]

Hello,

ich zanke mich noch mit meinen beiden MySQL-Servern rum.

wo muss in der my.cnf überall das Characterset und die Sortierung angegeben werden?

Steht zwar überall in allen Fehlermeldungen im Web, nachdem man

default-character-set= utf8
   default-collation = utf8_general_ci

in der my.cnf hinzugefügt hätte, wäre das Problem weg gewesen, aber leider steht nicht dabei, in welcher Section das sein muss. Ich möchte es nicht einfach blind in alle reinschreiben...

Ich bekomme immer diesen berühmt berüchtigten Fehler

"Illegal mix of collations"   --> swedish/german

Man konnte doch auch für die Connection sicherheitshalber ein encoding angeben, oder? Das ist hier mal so an mir vorbeigerauscht, leider finde ich es nicht wieder.

Zum "Spielen" verwende ich gerade SQL-Front. Da tritt der Fehler auf.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

na klasse :-((

jetzt hatte ich in die my.cnf des Servers unter

[client]

# added 20071126-ts
   character-set-server = latin1
   collation-server = latin1_general_ci

und

[mysqld]

# added 20071126-ts
   character-set-server = latin1
   collation-server = latin1_general_ci

mal testhalber die beiden Zeilen hinzugefügt.
Daraufhin konnte ich dann wenigstens mit SQL-Front auf die Tabellen und Prozeduren zugreifen, ohne den "mixed"-Fehler...

Dafür erhalte ich jetzt aber auf der Konsole den fehler:

testserver:[517]~# mysql -p
   mysql: unknown variable 'character-set-server=latin1'

Was nu?

Wie ist es denn nur richtig?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

jetzt hatte ich in die my.cnf des Servers unter

Alle Konfigurationsoptionen für den Server findest du unter Option and Variable Reference aufgelistet. Das ist ein Unterkapitel von "mysqld — The MySQL Server". Diese Optionen gelten also für den Teil [mysqld].

[client]

# added 20071126-ts
   character-set-server = latin1
   collation-server = latin1_general_ci

Ein Client interessiert sich nicht die Bohne für die Default-Einstellung des Servers. Die Optionen für Client-Programme findest du im Kapitel Client and Utility Programs.

Dafür erhalte ich jetzt aber auf der Konsole den fehler:

testserver:[517]~# mysql -p
   mysql: unknown variable 'character-set-server=latin1'
Wie ist es denn nur richtig?

default-character-set. Die Kollation ist dem Client auch egal, weil er nicht sortieren und vergleichen muss.

Es ist auch noch möglich, spezialisiertere [client]-Abschnitte zu verwenden, beispielsweise [mysql] für für das mysql-CLI.

Über das Thema Connection Character Sets and Collations gibt es ebenfalls ein Kapitel. Das ist zum Verständnis der insgesamt drei Konfigurationswerte für Client-Verbindungen nicht unwichtig.

echo "$verabschiedung $name";

[Tom]

Hello Dedlfix,

Alle Konfigurationsoptionen für den Server findest du unter Option and Variable Reference aufgelistet. Diese Optionen gelten also für den Teil [mysqld].

Dass die Einstellungen irgenwie unsinnig waren, dünkte mir schon.
Aber wie es so ist. Im Web fand ich denselben Blödsinn so ca. 10 Mal immer ähnlich und nichts anderes zu dem Thema und hab gedacht, naja, verstehen muss ich es jetzt ja nicht...

Ich werde mich da mal durchkämpfen.

Vielelleicht kannst Du mir noch eine Frage beantworten zum Thema
Declare ... Condition for ...

Es ist leider in http://dev.mysql.com/doc/refman/5.1/de/declare-conditions.html etwas dürftig erklärt. Was darf man als condition_value einsetzen und woher nehme ich die Werte?
Handelt es sich beid en MySQL-Fehlercodes um die von den ca. 39 Druckseiten?
http://dev.mysql.com/doc/refman/5.1/de/error-messages-server.html

Das bedeutet dann, entweder vierstelliger Code = MySQL-Fehlercode oder fünfstelliger = SQLSTATE laut Ansi SQL? Habe ich das richtig verstanden?

Was ich dabei nicht verstehe, wieso man die erst mit einem Namen verbinden muss, um sie dann mit dem Namen wieder in den Handler einbauen zu können.

Oder wie hängt das zusammen?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Es ist leider in http://dev.mysql.com/doc/refman/5.1/de/declare-conditions.html etwas dürftig erklärt. Was darf man als condition_value einsetzen und woher nehme ich die Werte?
Handelt es sich beid en MySQL-Fehlercodes um die von den ca. 39 Druckseiten?
http://dev.mysql.com/doc/refman/5.1/de/error-messages-server.html

Für mich reicht der Satz "A condition_value can be an SQLSTATE value or a MySQL error code." um daraus zu schlussfolgern, dass das so sein soll. Ein Test brächte mir dann Gewissheit, ob ich das richtig verstanden habe.

Das bedeutet dann, entweder vierstelliger Code = MySQL-Fehlercode oder fünfstelliger = SQLSTATE laut Ansi SQL? Habe ich das richtig verstanden?

So verstehe ich das auch.

Was ich dabei nicht verstehe, wieso man die erst mit einem Namen verbinden muss, um sie dann mit dem Namen wieder in den Handler einbauen zu können.

Anhand des Folgekapitels DECLARE Handlers kann ich keinen Zwang erkennen. Es ist vielmehr optional, eine Bedingung mit einem Namen zu versehen und diesen dann zu verwenden oder gleich die Bedingung in Form eines SQLSTATE-Wertes oder MySQL-Errorr-Codes anzugeben oder auch die drei allgemeinen, unspezifizierten Werte SQLWARNING, NOT FOUND, SQLEXCEPTION zu verwenden.

echo "$verabschiedung $name";

[Tom]

Hello,

Anhand des Folgekapitels DECLARE Handlers kann ich keinen Zwang erkennen. Es ist vielmehr optional, eine Bedingung mit einem Namen zu versehen und diesen dann zu verwenden oder gleich die Bedingung in Form eines SQLSTATE-Wertes oder MySQL-Errorr-Codes anzugeben oder auch die drei allgemeinen, unspezifizierten Werte SQLWARNING, NOT FOUND, SQLEXCEPTION zu verwenden.

Ja, vielen dank für Deine Einschätzung.

Ich probier das noch durch, wollte mir aber nicht irgendetwas falsches angewöhnen.

Ich sehe keinen wirklichen Nutzen darin, wenn beide Declares innerhalb der Prozedur oder Funktion stattfinden müssen, so wie ich das verstanden habe. Wenn die Namensbindung datenbankweit hergestellt werden könnte und die Bnetzung derselben dann innerhalb der Prozedur/Funktionsdeklaration, würde es mir sinnvoller erscheinen.

Das Ganze hat für mich als Ziel, Transaktionssteuerung in die Stored Procedure hineinzubringen. Ich hoffe, dass ich da nicht auf dem Holzweg bin. Es muss am Ende der Prozedur (oder bei Abbruch) ja irgendwie festgestellt werden, ob ein Rollback nötig ist oder nicht.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Tom]

Hello,

MySQL-Manual:

http://dev.mysql.com/doc/refman/5.1/de/cursors.html

Der Satz: "Cursors müssen vor Handlern und Variablen und Bedingungen vor Cursors und Handlern deklariert werden."

Und dann das Beispiel dazu:

CREATE PROCEDURE curdemo()
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE a CHAR(16);
  DECLARE b,c INT;
  DECLARE cur1 CURSOR FOR SELECT id,data FROM test.t1;
  DECLARE cur2 CURSOR FOR SELECT i FROM test.t2;
  DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;

OPEN cur1;
  OPEN cur2;

[...]

Verstehe ich da nun 'was falsch, oder widersprechen die MySQL-er sich da selbst?

Wie ist es denn nun richtig und vor allem, warum?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Vinzenz Mai]

Hallo

MySQL-Manual:

http://dev.mysql.com/doc/refman/5.1/de/cursors.html

warum MySQL 5.1? Ok, MySQL 5.1 geht allmählich auf den Status Release Candidate zu - verwenden würde ich persönlich MySQL 5.1 im Produktionseinsatz
noch auf keinen Fall. Siehe MySQL 5.0, wo in Version 5.0.12 kurz vor dem RC
die JOIN-Syntax inkompatibel geändert wurde.

Der Satz: "Cursors müssen vor Handlern und Variablen und Bedingungen vor Cursors und Handlern deklariert werden."

eine falsche Übersetzung wie Dir dem Original leicht hättest entnehmen können:

<zitat>
    Cursors must be declared before declaring handlers. Variables and
    conditions must be declared before declaring either cursors or handlers.
</zitat>

Text gleich bei der Doku von MySQL 5.0 und MySQL 5.1.

CREATE PROCEDURE curdemo()
BEGIN
  DECLARE done INT DEFAULT 0;
  DECLARE a CHAR(16);
  DECLARE b,c INT;
  DECLARE cur1 CURSOR FOR SELECT id,data FROM test.t1;
  DECLARE cur2 CURSOR FOR SELECT i FROM test.t2;
  DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;

OPEN cur1;
  OPEN cur2;

[...]

Verstehe ich da nun 'was falsch,

Nein.

oder widersprechen die MySQL-er sich da selbst?

Nein, nur ein Übersetzungsfehler.

Wie ist es denn nun richtig und vor allem, warum?

Lies das Original:
Cursors (5.0)
Cursors (5.1)

Freundliche Grüße

Vinzenz

[Tom]

Hello Vinzenz,

noch einen "Adlerpunkt" für Dich. :-)

Hätte ich ja auch mal selber drauf kommen können .
Aber bisher hat bei MySQL, im Gegensatz zu PHP, immer alles gestimmt im deutschen Manual.

warum MySQL 5.1?

Ich verwende 5.0.32-Debian_7etch1-log
Das hat angeblich schon diverse Implementationen aus dem 5.1
Bisher hat es zumindest auch immer so ausgesehen.

eine falsche Übersetzung wie Dir dem Original leicht hättest entnehmen können:

<zitat>
    Cursors must be declared before declaring handlers. Variables and
    conditions must be declared before declaring either cursors or handlers.
</zitat>

So ist es irgendwie auch logisch.

Lies das Original:
Cursors (5.0)
Cursors (5.1)

Gibt es Unterschiede?
Dann muss ich erstmal realisieren, welche Manual-Version nun auf "meine" DB-Version zutrifft

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom