Lebensdauer von SET-Befehlen

Moin,

wie lange leben die Einstellungen, die ich mit SET-Befehlen wie=20

set character_set_results=3Dutf8;

mache? Das SET soll Statndardeinstellungen überschreiben (klar). Gilt=20
das bis zum nächsten connect (bzw. bei PHP bis mysql_close)? Ich=20
probiere verschiedenes in der mysql-Konsole, mache zwischendurch immer=20
mal "show variables" und sehe, daß die alten Einstellungen wieder da=20
stehen.

Ralph

Re: Lebensdauer von SET-Befehlen

Ralph Stahl schrieb:
> Moin,
>
> wie lange leben die Einstellungen, die ich mit SET-Befehlen wie
>
> set character_set_results=utf8;
>
> mache? Das SET soll Statndardeinstellungen überschreiben (klar). Gilt
> das bis zum nächsten connect (bzw. bei PHP bis mysql_close)? Ich
> probiere verschiedenes in der mysql-Konsole, mache zwischendurch immer
> mal "show variables" und sehe, daß die alten Einstellungen wieder da
> stehen.
>

Wenn Du wissen willst, ob die Einstellungen ein disconnect überleben,
beende einfach die Konsole und starte eine neue. Außerdem ist
natürlich interessant, ob das über eine Connection hinweg geht - also
in einem anderen Terminal ein zweites mysql starten und gucken...

Man *könnte* auch das Handbuch lesen. Aber das ist eine ziemlich
unbeliebte Tätigkeit - schließlich gibt's das Usenet.

Re: Lebensdauer von SET-Befehlen

Christian Kirsch schrieb:
> Ralph Stahl schrieb:
>> Moin,
>>
>> wie lange leben die Einstellungen, die ich mit SET-Befehlen wie
>>
>> set character_set_results=utf8;
>>
>> mache? Das SET soll Statndardeinstellungen überschreiben (klar). Gilt
>> das bis zum nächsten connect (bzw. bei PHP bis mysql_close)? Ich
>> probiere verschiedenes in der mysql-Konsole, mache zwischendurch immer
>> mal "show variables" und sehe, daß die alten Einstellungen wieder da
>> stehen.
>>
>
> Wenn Du wissen willst, ob die Einstellungen ein disconnect überleben,
> beende einfach die Konsole und starte eine neue. Außerdem ist
> natürlich interessant, ob das über eine Connection hinweg geht - also
> in einem anderen Terminal ein zweites mysql starten und gucken...
>
> Man *könnte* auch das Handbuch lesen. Aber das ist eine ziemlich
> unbeliebte Tätigkeit - schließlich gibt's das Usenet.

Nein, es ist nicht unbeliebt, aber ich habe es so nicht gefunden. Aber
ausprobiert wie vorgeschlagen, und nun weiß ich es.

Danke!
Ralph

Re: Lebensdauer von SET-Befehlen

In schrieb ck@bru6.de:
> Ralph Stahl schrieb:
> > Moin,
> >=20
> > wie lange leben die Einstellungen, die ich mit SET-Befehlen wie=20
> >=20
> > set character_set_results=3Dutf8;
> >=20
> > mache? Das SET soll Statndardeinstellungen überschreiben (klar). Gilt=
=20
> > das bis zum nächsten connect (bzw. bei PHP bis mysql_close)? Ich=20
> > probiere verschiedenes in der mysql-Konsole, mache zwischendurch immer=
=20
> > mal "show variables" und sehe, daß die alten Einstellungen wieder da=
=20
> > stehen.
> >=20
>=20
> Wenn Du wissen willst, ob die Einstellungen ein disconnect überleben,
> beende einfach die Konsole und starte eine neue. Außerdem ist
> natürlich interessant, ob das über eine Connection hinweg geht - also
> in einem anderen Terminal ein zweites mysql starten und gucken...
>=20
> Man *könnte* auch das Handbuch lesen. Aber das ist eine ziemlich
> unbeliebte Tätigkeit - schließlich gibt's das Usenet.

Ich würde nicht fragen, wenn ich es passend gefunden hätte.

Ich habe gefunden "Jede Option, die Sie setzen, bleibt in Kraft, bis die=20
aktuelle Sitzung beendet wird". Das würde heißen, bis zum nächsten=20
connect oder (mit PHP) zum mysql_close(). Oder wann ist eine Sitzung zu=20
Ende, wenn ich mit PHP arbeite?

Ralph

Re: Lebensdauer von SET-Befehlen

HI Ralph

Ralph Stahl wrote:
> In schrieb ck@bru6.de:
>> Man *könnte* auch das Handbuch lesen. Aber das ist eine ziemlich
>> unbeliebte Tätigkeit - schließlich gibt's das Usenet.
> Ich würde nicht fragen, wenn ich es passend gefunden hätte.
> Ich habe gefunden "Jede Option, die Sie setzen, bleibt in Kraft, bis die
> aktuelle Sitzung beendet wird". Das würde heißen, bis zum nächsten
> connect oder (mit PHP) zum mysql_close(). Oder wann ist eine Sitzung zu
> Ende, wenn ich mit PHP arbeite?

Dein deutsches Zitat lässt mich vermuten, dass du dich noch mit
deutschen Handbüchern rumschlägst. Achtung, die sind immer etwas
veraltet. Stattdessen empfehle ich dir die englische Version.

Ja, bei PHP ist die Sitzung mit mysql_close() beendet. Nach Ausführung
eines Scripts wird ebenfalls intern ein mysql_close() ausgeführt (Alle
Ressourcen müssen freigegeben werden).

HTH, Johannes

Re: Lebensdauer von SET-Befehlen

Johannes Vogel wrote:

> Ja, bei PHP ist die Sitzung mit mysql_close() beendet. Nach Ausführung
> eines Scripts wird ebenfalls intern ein mysql_close() ausgeführt (Alle
> Ressourcen müssen freigegeben werden).

(OT:) Nicht, wenn man die Verbindung mit mysql_pconnect eröffnet hat (was
man aber eh nicht will). Dann lebt die Verbindung persistent weiter.

Thomas
--
Sind wir nicht alle ein bisschen Bielefeld? (Jörg Wagner in dcsm)

Re: Lebensdauer von SET-Befehlen

Hi Thomas

Thomas Rachel wrote:
> Johannes Vogel wrote:
>> Ja, bei PHP ist die Sitzung mit mysql_close() beendet. Nach Ausführung
>> eines Scripts wird ebenfalls intern ein mysql_close() ausgeführt (Alle
>> Ressourcen müssen freigegeben werden).
> (OT:) Nicht, wenn man die Verbindung mit mysql_pconnect eröffnet hat (was
> man aber eh nicht will). Dann lebt die Verbindung persistent weiter.

Das gibt dann aber doppelt Probleme. Weil du ja nicht weisst, ob die
bereits offene Verbindung diese Einstellung bereits vorgenommen hat,
oder nicht.

Wie du bereits erwähnt hast, will man das nicht.
Johannes

Re: Lebensdauer von SET-Befehlen

Thomas Rachel wrote:
> Johannes Vogel wrote:
>
>> Ja, bei PHP ist die Sitzung mit mysql_close() beendet. Nach Ausführung
>> eines Scripts wird ebenfalls intern ein mysql_close() ausgeführt (Alle
>> Ressourcen müssen freigegeben werden).
>
> (OT:) Nicht, wenn man die Verbindung mit mysql_pconnect eröffnet hat (was
> man aber eh nicht will). Dann lebt die Verbindung persistent weiter.

Bei den üblichen multiprocessed Apache/mod_PHP Setups kann man mit
mysql_pconnect() in ganz neue Sphären überraschender Fehler vorstoßen.

Das geht damit los, daß man nicht weiß in welchem Zustand man seine
Session vorfindet. Session/User-Variablen können in beliebigen
Zuständen sein. Es kann offene Transaktionen geben, temporäre Tabellen
liegen herum und womöglich hat man auch noch ein paar LOCKs vom
Vorgänger "geerbt".

Spätestens wenn mal ein PHP-Skript LOCK TABLES abgesetzt hat und vor
dem UNLOCK unerwartet verstorben ist, wird der DBA den PHP-Entwickler
besuchen und ihm die Verwendung von pconnect() ausreden. Argumentative
Unterstützung durch einen schweren, harten Gegenstand nicht
ausgeschlossen ;-)

Mal ernst: pconnect() versucht, ein nichtexistierendes Problem zu lösen
(MySQLs connect() ist sauschnell) und ist ein tolles Beispiel für
"premature optimization". Bitte *niemals* verwenden.


XL