Hilfe: MySQL startet plötzlich nicht mehr

Hallo zusammen,

ich verwende MySQL nun seit 2 Jahren ohne große Probleme. Vor ca. 9
Monaten habe ich auf 5.0 umgestellt. Die Datenbank liegt auf einem
Windows Small Business Server, die Clients greifen über ein ACCESS
Frontend drauf zu. Alle wunderbar...

Heute habe ich einige Tabellen und SP geändert; plötzlich Fehler
2003, keine Anmeldung mehr.Und die krieg ich auch nicht mehr! Der
Fehler trat auf, während ein neues Feld in eine Tabelle eingefügt
wurde. Also eigentlich eine triviale Sache.. Hab den Server runter-
und raufgefahren.. MySQL startet nicht wirklich.

Ich beschreib das mal genauer: Wenn der Server gerade hochgefahren ist,
komme ich über den MySQL-Administrator zu MySQL. Ich kann dann auch
die Datenbanken in der Übersicht sehen. Sobald ich aber auf ein der
Datenbanken zugreife, flieg ich raus. Auch auf der CommandLine-Ebene
ist tote Hose. Die Eingabe von "mysql" wird quittiert mit "no
connection." Auch der Zugriff über den ODBC-Treiber führt zur
sofortigen Totalverabschiedung. Um ein kurzes Reinkommen zu bekommen,
muss ich den Windowsserver ganz runterfahren und wieder rauffahren.
Aber das bringt alles nix...

Hat einer ne Ahnung, was das ist? Und, noch viel wichtiger: Wie kann
man das reparieren... Ich wollte, bevor ich die große Klatsche
raushole, mich lieber noch mal erkundigen, ob mir jemand da Tipps geben
kann. Wär super..., besonders weil die
MySQL-Administrationseinstellungen sicher nicht mein Steckenpferd
sind... (<-- zumal ich ja auch gar nicht rankomme..)=20

:-(

Re: Hilfe: MySQL startet plötzlich nicht mehr

Hi slize

slize wrote:
^-- Realnamen sind hier willkommen!
> ich verwende MySQL nun seit 2 Jahren ohne große Probleme. Vor ca. 9
> Monaten habe ich auf 5.0 umgestellt. Die Datenbank liegt auf einem
> Windows Small Business Server, die Clients greifen über ein ACCESS
> Frontend drauf zu. Alle wunderbar...

Prima. Bei solchen Fehlern interessiert aber eigentlich nur mal der
Konsolen-Zugang. Alles andere ist dann Sache der einzelnen Komponenten.

> Heute habe ich einige Tabellen und SP geändert; plötzlich Fehler
> 2003, keine Anmeldung mehr.Und die krieg ich auch nicht mehr! Der
> Fehler trat auf, während ein neues Feld in eine Tabelle eingefügt
> wurde. Also eigentlich eine triviale Sache.. Hab den Server runter-
> und raufgefahren.. MySQL startet nicht wirklich.

Ok. MySQL startet nicht wirklich. Dazu gibt's doch ein Log-File. Wo
liegt, sei mal dahingestellt, weil du uns nicht mal verrätst, welches OS
du verwendest. Es befindet sich normalerweise da, wo sich auch die
DB-Files befinden (/usr/local/mysql/data/ oder /var/mysql o.ä.). Aber in
diesem Logfile kann man nachschauen, ob und falls nicht, wieso der MySQL
Server nicht korrekt startet. Das kann man dann beheben und dann darauf
hoffen, dass alles andere sofort reibungslos läuft...

HTH, Johannes

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Hilfe: MySQL startet plötzlich nicht mehr

Hi Andreas

Andreas Kretschmer wrote:
> begin Johannes Vogel wrote:
>> Hi slize
>> slize wrote:
>> ^-- Realnamen sind hier willkommen!
>>> ich verwende MySQL nun seit 2 Jahren ohne große Probleme. Vor ca. 9
>>> Monaten habe ich auf 5.0 umgestellt. Die Datenbank liegt auf einem
>>> Windows Small Business Server, die Clients greifen über ein ACCESS
>> Ok. MySQL startet nicht wirklich. Dazu gibt's doch ein Log-File. Wo
>> liegt, sei mal dahingestellt, weil du uns nicht mal verrätst, welches OS
>> du verwendest. Es befindet sich normalerweise da, wo sich auch die
> Doch, tut er. In allen anderen Punkten hast Du latürnich Recht.

Oups, gerade überlesen... Naja, aber auch da ist das Logfile irgendwo zu
finden. Bei mir liegt's hier:
C:\Programme\MySQL\MySQL Server 5.0\data\.err

HTH, Johannes

Re: Hilfe: MySQL startet plötzlich nicht mehr

Hallo zusammen,

das System läuft wieder allerdings..

Es ging aber leider erst nach De- und Neuinstallation des DB-Servers.
Zudem mussten alle Datenbanken wieder neu aufgebaut werden. Zum Glück
hatte ich Sicherungen.

Ich vermute es ist folgendes passiert: Beim Ändern einer Tabelle hat
sich das information-scheme nicht entsprechend aktualisiert; unnter
Umständen aufgrund eines Netzwerkfehlers bei mir (da ich die Tabellen
immer an einem Clientrechner bearbeite..) Der Server verabschiedete
sich nämlich beim Zugriff auf diese bestimmte Tabelle.

Ich habe dann gleich von 5.020 auf 5.027 umgestellt. Seltsamerweise
geht jetzt eine der Abfragen nicht mehr... (VIEW auf VIEW).

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas Kretschmer wrote:
> slize wrote:

>> Ich habe dann gleich von 5.020 auf 5.027 umgestellt. Seltsamerweise
>> geht jetzt eine der Abfragen nicht mehr... (VIEW auf VIEW).

> Willkommen in der wunderbaren Welt von MySQL. Während z.B. SELECT
> COUNT(1) unter 5.0.24a 0 liefert, kommt bei 5.0.27 richtigerweise 1.

Hmm. Was ist so ungewöhnlich daran, daß eine neue Version von MySQL
einen alten Bug nicht mehr enthält? Haben alte Versionen von PostgreSQL
keine Bugs? Oder werden die nicht gefixt?


XL

Re: =?iso-8859-1?q?Re:_Hilfe:_MySQL_startet_plötzlich_nicht_mehr?

"slize" wrote:
> Hallo zusammen,
>
> das System läuft wieder allerdings..
>
> Es ging aber leider erst nach De- und Neuinstallation des DB-Servers.
> Zudem mussten alle Datenbanken wieder neu aufgebaut werden. Zum Glück
> hatte ich Sicherungen.

Und wieder geht ein fettes "Dankeschön!" nach Redmond für die
Verbreitung der Idee, eine Neuinstallation wäre der ultimative
Ansatz für die Lösung eines Softwareproblems.

Falls tatsächlich eine Tabelle so beschädigt war, daß MySQL
beim Zugriff darauf abstürzt, hätte Reparieren auch ohne
Neuinstallation gereicht.

http://dev.mysql.com/doc/refman/5.0/en/crashing.html
http://dev.mysql.com/doc/refman/5.0/en/table-maintenance.htm l

> Ich vermute es ist folgendes passiert: Beim Ändern einer Tabelle hat
> sich das information-scheme nicht entsprechend aktualisiert;

Vollkommen daneben. Das Information Schema ist nirgendwo im Server
materialisiert. Es existiert lediglich rein virtuell in Form von
Verzeichnissen und Dateien im MySQL-Datadir.

> unnter
> Umständen aufgrund eines Netzwerkfehlers bei mir (da ich die Tabellen
> immer an einem Clientrechner bearbeite..)

Irrelevant. Naja, zumindest solange du nicht in Access-Manier das
Datenfile für "die Datenbank" hältst und über die Windows-Freigabe
darauf zugreifst. In diesem Fall wäre eine kaputte Datenbank
allerdings der Normalfall.

> Der Server verabschiedete
> sich nämlich beim Zugriff auf diese bestimmte Tabelle.

Ein Blick in das Errorlog hätte bestätigt, daß MySQL crasht.
CHECK TABLE existiert. REPAIR TABLE auch.

> Ich habe dann gleich von 5.020 auf 5.027 umgestellt. Seltsamerweise
> geht jetzt eine der Abfragen nicht mehr... (VIEW auf VIEW).

Details? Unter welcher Bug-ID hast du dieses Problem
bei bugs.mysql.com reported?

Ich kann Unmut angesichts eines Bugs verstehen, allerdings reparieren
sich Bugs nicht von alleine. Und wenn die Verantwortlichen noch nicht
mal von der Existenz des Bugs wissen, schonmal gar nicht.


XL

Re: Hilfe: MySQL startet plötzlich nicht mehr

Andreas Kretschmer wrote:

> Willkommen in der wunderbaren Welt von MySQL. Während z.B. SELECT
> COUNT(1) unter 5.0.24a 0 liefert, kommt bei 5.0.27 richtigerweise 1.

Warum sollte 1 richtig und 0 falsch sein?
Ich würde eher 0 erwarten, da es auf einer leeren Menge arbeitet.

Aber so ist das Ergebnis dann zumindest das Gleiche wie beim MS SQL
Server :-)

Dieter

Re: Hilfe: MySQL startet plötzlichnicht mehr

Axel Schwenke wrote:
> Andreas Kretschmer wrote:
>
>> Willkommen in der wunderbaren Welt von MySQL. Während z.B. SELECT
>> COUNT(1) unter 5.0.24a 0 liefert, kommt bei 5.0.27 richtigerweise 1.
>
> Hmm. Was ist so ungewöhnlich daran, daß eine neue Version von MySQL
> einen alten Bug nicht mehr enthält? Haben alte Versionen von PostgreSQL
> keine Bugs? Oder werden die nicht gefixt?

Die Frage ist wohl eher, warum man ein Ausgabeverhalten in einem
Mikrorelease ändert und was an dieser Änderung noch alles hinten dran
hängt, was ich nun nicht noch im Changelog/Source nach schauen wollte.


Bye

--
Andreas 'ads' Scherbaum
Explaining the concept of referential integrity to a mysql user is
like explaining condoms to a catholic

Re: Hilfe: MySQL startet plötzlichnicht mehr

Dieter Noeth wrote:
> Andreas Kretschmer wrote:
>
>> Willkommen in der wunderbaren Welt von MySQL. Während z.B. SELECT
>> COUNT(1) unter 5.0.24a 0 liefert, kommt bei 5.0.27 richtigerweise 1.
>
> Warum sollte 1 richtig und 0 falsch sein?
> Ich würde eher 0 erwarten, da es auf einer leeren Menge arbeitet.

Seit wann ist '1' eine leere Menge?


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Hilfe: MySQL startet plötzlich nicht mehr

Andreas Scherbaum wrote:

>> Warum sollte 1 richtig und 0 falsch sein?
>> Ich würde eher 0 erwarten, da es auf einer leeren Menge arbeitet.
>
> Seit wann ist '1' eine leere Menge?

Ein "select 1" liefert eine Row,
ein "select count(*) from (select 1 x) dt" sollte 1 liefern,
ein "select count(1)" ist aber das gleiche wie ein "select count(*)" und
das sind alle Rows in dieser Menge und für mich ist die leer.

Deshalb gibt's ja auch kein Select ohne From im Standard SQL.

Dieter

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas Scherbaum wrote:
> Axel Schwenke wrote:
>> Andreas Kretschmer wrote:
>>
>>> Willkommen in der wunderbaren Welt von MySQL. Während z.B. SELECT
>>> COUNT(1) unter 5.0.24a 0 liefert, kommt bei 5.0.27 richtigerweise 1.
>>
>> Hmm. Was ist so ungewöhnlich daran, daß eine neue Version von MySQL
>> einen alten Bug nicht mehr enthält? Haben alte Versionen von PostgreSQL
>> keine Bugs? Oder werden die nicht gefixt?
>
> Die Frage ist wohl eher, warum man ein Ausgabeverhalten in einem
> Mikrorelease ändert und was an dieser Änderung noch alles hinten dran
> hängt, was ich nun nicht noch im Changelog/Source nach schauen wollte.

Tatsächlich zeigt weder das Changelog von 5.0.26 (5.0.25 liefert noch 0
und 5.0.27 enthält keine nennenswerten Code-Änderungen) noch das Bug-
trackingsystem einen Grund für das veränderte Verhalten. Ich nenne das
einen "Documentation Bug" -> http://bugs.mysql.com/25365

Bezüglich des Releasezeitpunktes: diese Änderung betrifft die Reaktion
des MySQL-Servers auf grenzwertiges SQL. Niemand außer QA-Leuten oder
PostgreSQL-Trollen mit Fixierung auf MySQL-Gotchas ;-) schreibt sowas.
Es gibt also keinen Grund, diese Änderung bis zum nächsten Major-
Release zurückzustellen.


Nachdem ich mittlerweile nochmal darüber nachgedacht habe, bin ich mir
nicht mehr so sicher, warum 1 das richtige Ergebnis sein sollte.

Als Aggregatfunktion operiert COUNT() auf einer Ergebnismenge, eine
solche ist bei einem skalaren SELECT aber nicht vorhanden. Das Ergebnis
0 ist also nicht unbedingt falsch. Offensichtlich wurde das bei MySQL
bis 5.0.25 genau so gesehen.

Seit 5.0.26 wertet MySQL die Aggregatfunktionen im skalaren Kontext
anders aus, so als wäre da eine einzelne Zeile. Ob das richtiger ist
als vorher, mag ich nicht beurteilen. Der Standard wird das bestimmt
irgendwo festlegen, allerdings hat MySQL mit Peter Gulutzan da einen
anerkannten Experten am Start.


XL

Re: Hilfe: MySQL startet plötzlichnicht mehr

Axel Schwenke wrote:
> Andreas Scherbaum wrote:
>>
>> Die Frage ist wohl eher, warum man ein Ausgabeverhalten in einem
>> Mikrorelease ändert und was an dieser Änderung noch alles hinten dran
>> hängt, was ich nun nicht noch im Changelog/Source nach schauen wollte.
>
> Tatsächlich zeigt weder das Changelog von 5.0.26 (5.0.25 liefert noch 0
> und 5.0.27 enthält keine nennenswerten Code-Änderungen) noch das Bug-
> trackingsystem einen Grund für das veränderte Verhalten. Ich nenne das
> einen "Documentation Bug" -> http://bugs.mysql.com/25365

Hey, toll, Danke das du mir die Arbeit abgenommen hast.
Bisher war ich zu faul, um wirklich das Changelog durchzusehen (wie
geschrieben) und habe mal positv angenommen, das es wenigstens dort
vermerkt wird. Danke das du meine Hoffnungen zerstörst :-(


> Bezüglich des Releasezeitpunktes: diese Änderung betrifft die Reaktion
> des MySQL-Servers auf grenzwertiges SQL. Niemand außer QA-Leuten oder
> PostgreSQL-Trollen mit Fixierung auf MySQL-Gotchas ;-) schreibt sowas.

Stellt sich mir die Frage, wieso ausgerechnet du jedesmal anspringst,
wenn jemand über Probleme berichtet. Diesen Reflex kannst du mal
abstellen, damit man mit dir vernünftig diskutieren kann.


> Nachdem ich mittlerweile nochmal darüber nachgedacht habe, bin ich mir
> nicht mehr so sicher, warum 1 das richtige Ergebnis sein sollte.

Weil die Menge eines Ergebnisses gezählt werden soll und nun mal ein
Ergebnis als Input gegeben ist? Wenn Mysql die '1' nicht als gültigen
Input zum Zählen ansieht, wäre eine Fehlermeldung der richtige Weg,
dies dem User mitzuteilen.


> Als Aggregatfunktion operiert COUNT() auf einer Ergebnismenge, eine
> solche ist bei einem skalaren SELECT aber nicht vorhanden. Das Ergebnis
> 0 ist also nicht unbedingt falsch. Offensichtlich wurde das bei MySQL
> bis 5.0.25 genau so gesehen.
>
> Seit 5.0.26 wertet MySQL die Aggregatfunktionen im skalaren Kontext
> anders aus, so als wäre da eine einzelne Zeile. Ob das richtiger ist
> als vorher, mag ich nicht beurteilen. Der Standard wird das bestimmt
> irgendwo festlegen, allerdings hat MySQL mit Peter Gulutzan da einen
> anerkannten Experten am Start.

Da wurde also offensichtlich doch mehr geändert, als nur ein 0 oder 1
auszugeben. Soviel zu Minor Releases, oder?


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Hilfe: MySQL startet plötzlichnicht mehr

Dieter Noeth wrote:
> Andreas Scherbaum wrote:
>
>>> Warum sollte 1 richtig und 0 falsch sein?
>>> Ich würde eher 0 erwarten, da es auf einer leeren Menge arbeitet.
>>
>> Seit wann ist '1' eine leere Menge?
>
> Ein "select 1" liefert eine Row,

Oh, da ist also eine Menge vorhanden.


> ein "select count(*) from (select 1 x) dt" sollte 1 liefern,

Hier auch.


> ein "select count(1)" ist aber das gleiche wie ein "select count(*)" und
> das sind alle Rows in dieser Menge und für mich ist die leer.

Also warum liefert die erste Zeile ein Result zurück und das wird nicht
gezählt? Ich kann oder mag deiner Logik hier nicht ganz folgen.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Hilfe: MySQL startet plötzlich nicht mehr

Andreas Scherbaum wrote:

>> ein "select count(1)" ist aber das gleiche wie ein "select count(*)" und
>> das sind alle Rows in dieser Menge und für mich ist die leer.
>
> Also warum liefert die erste Zeile ein Result zurück und das wird nicht
> gezählt? Ich kann oder mag deiner Logik hier nicht ganz folgen.

Weil ein "Select 1" eine Row mit dem Wert 1 liefert, diese Menge kann
gezählt werden.
Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
einem "*", also alle Rows der Menge. Diese Menge existiert aber nicht.
Jetzt ist Count die einzige Aggregat-Funktion, die auch bei einer leeren
Menge eine Antwortmenge liefert, nämlich die 0. Diese Row ist aber das
Ergebnis des Counts und wird natürlich nicht mitgezählt.

Für mich klingt das logisch :-)

Dieter

Re: Hilfe: MySQL startet plötzlichnicht mehr

Dieter Noeth wrote:
> Andreas Scherbaum wrote:
>
>> Also warum liefert die erste Zeile ein Result zurück und das wird nicht
>> gezählt? Ich kann oder mag deiner Logik hier nicht ganz folgen.
>
> Weil ein "Select 1" eine Row mit dem Wert 1 liefert, diese Menge kann
> gezählt werden.
> Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
> einem "*", also alle Rows der Menge. Diese Menge existiert aber nicht.

Noch mal für mich: Da ist also eine Menge in den Klammern vorhanden, die
Mysql anderweitig auch deutlich als einen Row ausgibt. Aber sobald diese
Menge gezählt werden soll, ist sie nicht mehr vorhanden? Wohin verschwindet
sie denn deiner Meinung nach?

Der Datenbank ist es doch egal, woher die Menge kommt, die sie zählen soll.
Ob die Daten nun aus einer Tabelle oder einfach nur dem Select kommen.

Das eine "1" einem "*" entspricht, dieser Meinung möchte ich mich nicht
anschliessen. Schliesslich ist die "1" vorhanden und das Sternchen ist bloss
ein Synonym für die Menge aller vorhandenen Spalten.

Umgekehrt kannst du natürlich sagen, das "*" der Menge "1" entspricht, aber
solange nur Sterne und keine Werte vorhanden sind, ist die Menge sowieso leer.
Das dürfte dann in etwa dem früher hier erwähnten Beispiel:
> select count(*) from (select 1 x) dt;
entsprechen.


> Jetzt ist Count die einzige Aggregat-Funktion, die auch bei einer leeren
> Menge eine Antwortmenge liefert, nämlich die 0. Diese Row ist aber das
> Ergebnis des Counts und wird natürlich nicht mitgezählt.

Also meine Mysql Version gibt mir bei einer leeren Menge einen Fehler zurück,
das ich doch bitte an meiner SQL Syntax arbeiten soll. Zwischen deiner
Definition einer leeren Menge und meiner muss ein Unterschied liegen.


> Für mich klingt das logisch :-)

Für mich nur verdreht, aber nicht logisch.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

COUNT() (was: Hilfe: MySQL startet plötzlichnicht mehr)

Dieter Noeth wrote:

> Weil ein "Select 1" eine Row mit dem Wert 1 liefert, diese Menge kann
> gezählt werden.

Soweit klar.


> Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
> einem "*", also alle Rows der Menge.

Prinzipiell ja, wie mir nach etwas Nachdenken einleuchtet. Für jedes
Element der Menge wird festgestellt, ob das Argument NOT NULL ist. Und
das ist bei 1 ja immer der Fall.


> Diese Menge existiert aber nicht.

Das wiederum stimmt nicht - die Anzahl der Rows ist tatsächlich 1,
nämlich die zurückgegebene - solange keine Tabelle angegeben wurde.

IMHO kann man

SELECT 1;

schreiben als

SELECT a FROM (SELECT 1 AS a) AS t;

wobei die "innere" Tabelle t genau einen Row zurückliefert.

Dasselbe gilt dann auch für

SELECT COUNT(71);
und
SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT 22 AS a) AS t;

und auch

SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT 22 AS a UNION SELECT 33)
AS t;


Liefert die innere Tabelle nichts zurück, kommt auch 0 raus:

SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT NULL AS a LIMIT 0) AS t;


Thomas
--
while(!asleep()) sheep++;

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas Scherbaum wrote:
> Dieter Noeth wrote:
>> Andreas Scherbaum wrote:
>>
>>> Also warum liefert die erste Zeile ein Result zurück und das wird nicht
>>> gezählt? Ich kann oder mag deiner Logik hier nicht ganz folgen.
>>
>> Weil ein "Select 1" eine Row mit dem Wert 1 liefert, diese Menge kann
>> gezählt werden.
>> Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
>> einem "*", also alle Rows der Menge. Diese Menge existiert aber nicht.
>
> Noch mal für mich: Da ist also eine Menge in den Klammern vorhanden

Die Menge steht nicht in den Klammern. Wie jede andere Aggregatfunktion
wird COUNT() in Anwesenheit einer GROUP BY Klausel einmal pro Gruppe
ausgewertet, ansonsten einmal pro gesamter Ergebnismenge. Ein SELECT
ohne FROM kann aber nie eine Ergebnismenge haben, sondern lediglich
skalare Objekte abfragen.

Das Argument zu COUNT() ist ein Ausdruck, der bestimmt, was COUNT()
zählen soll. Allgemein: die Anzahl aller Zeilen der Gruppe für die der
Ausdruck NOT NULL ist.

Speziell heißt das: COUNT(*), COUNT(1), COUNT(42) und COUNT(0) zählt
immer die Anzahl der Zeilen in der Gruppe. Traditionell verwendet man
allerdings meistens COUNT(*) dafür. COUNT(NULL) liefert immer 0.

>> Jetzt ist Count die einzige Aggregat-Funktion, die auch bei einer leeren
>> Menge eine Antwortmenge liefert, nämlich die 0. Diese Row ist aber das
>> Ergebnis des Counts und wird natürlich nicht mitgezählt.
>
> Also meine Mysql Version gibt mir bei einer leeren Menge einen Fehler zurück,
> das ich doch bitte an meiner SQL Syntax arbeiten soll. Zwischen deiner
> Definition einer leeren Menge und meiner muss ein Unterschied liegen.

Die leere Menge ist was anderes als keine Menge. Für die leere Menge
gibt COUNT(*) auch brav eine 0 zurück:

~ $mysql test
....
Server version: 5.0.34-debug Source distribution

mysql> create table t1 (c1 int);
mysql> truncate table t1;

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 0 |
+----------+

mysql> select count(*);
+----------+
| count(*) |
+----------+
| 1 |
+----------+


XL

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas Scherbaum wrote:
> Axel Schwenke wrote:

>> Bezüglich des Releasezeitpunktes: diese Änderung betrifft die Reaktion
>> des MySQL-Servers auf grenzwertiges SQL. Niemand außer QA-Leuten oder
>> PostgreSQL-Trollen mit Fixierung auf MySQL-Gotchas ;-) schreibt sowas.
>
> Stellt sich mir die Frage, wieso ausgerechnet du jedesmal anspringst,
> wenn jemand über Probleme berichtet.

Du hast schon mal über Probleme berichtet? Zeigen! Der Einstieg des
Andreas & Andreas Troll-Duos in diesen Thread war mal wieder ein
typisches Trollposting. Nichts weiter.

> Diesen Reflex kannst du mal abstellen, damit

Du meinst, ich soll offensichtliche Trollpostings ignorieren? Ja, wäre
vermutlich besser, denn schließlich kann ich die Hoffnung, daß

> man mit dir vernünftig diskutieren kann.

besser gleich ganz aufgeben.

Wenn du tatsächlich ein Problem mit dem neuen Verhalten von COUNT()
gehabt hättest, dann wäre ein Bugreport oder zumindest eine Nachfrage
hier die normale Reaktion gewesen.

>> Seit 5.0.26 wertet MySQL die Aggregatfunktionen im skalaren Kontext
>> anders aus, so als wäre da eine einzelne Zeile.

> Da wurde also offensichtlich doch mehr geändert, als nur ein 0 oder 1
> auszugeben.

Ja. Schrieb ich doch. Das Verhalten von Aggregatfunktionen im skalaren
Kontext wurde geändert. Anscheinend vollständig und konsistent.
Nur eben leider undokumentiert.

> Soviel zu Minor Releases, oder?

An sich sollten behaviour changes nur dann in Minor Releases
auftauchen, wenn sie offensichtliche Bugs beheben.

Aber wie ich bereits schrieb bezieht sich diese Änderung auf SQL-
Statements, die an sich schon sinnlos sind. Daß du Aggregatfunktionen
im allgemeinen und COUNT() im speziellen nicht begriffen zu haben
scheinst, wirst du ja wohl nicht MySQL anlasten wollen.


XL

Re: Hilfe: MySQL startet plötzlichnicht mehr

Andreas
--
Andreas Kretschmer
Linux - weil ich es mir wert bin!
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
Deutsche PostgreSQL User Group: http://pgug.de

Re: Hilfe: MySQL startet plötzlichnicht mehr

Axel Schwenke wrote:
> Andreas Scherbaum wrote:
>> Dieter Noeth wrote:
>>> Andreas Scherbaum wrote:
>>>
>>>> Also warum liefert die erste Zeile ein Result zurück und das wird nicht
>>>> gezählt? Ich kann oder mag deiner Logik hier nicht ganz folgen.
>>>
>>> Weil ein "Select 1" eine Row mit dem Wert 1 liefert, diese Menge kann
>>> gezählt werden.
>>> Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
>>> einem "*", also alle Rows der Menge. Diese Menge existiert aber nicht.
>>
>> Noch mal für mich: Da ist also eine Menge in den Klammern vorhanden
>
> Die Menge steht nicht in den Klammern. Wie jede andere Aggregatfunktion
> wird COUNT() in Anwesenheit einer GROUP BY Klausel einmal pro Gruppe
> ausgewertet, ansonsten einmal pro gesamter Ergebnismenge.

Count zählt, laut Mysql Doku, die Anzahl von nicht-Null Werten in den
zurückgelieferten Zeilen. Eine 1 ist schon mal nicht NULL, also ist es
ein zählbarer Wert. Dies wird jetzt auch so gehandhabt.


> Ein SELECT ohne FROM kann aber nie eine Ergebnismenge haben, sondern
> lediglich skalare Objekte abfragen.

Soll ich jetzt sagen: dann ist die Dokumentation falsch, weil dort nur
von Werten (Values) gesprochen wird, nicht von skalaren Objekten.
Oder soll ich sagen: ein einzelner Wert ist auch Teil einer Menge.


> Das Argument zu COUNT() ist ein Ausdruck, der bestimmt, was COUNT()
> zählen soll. Allgemein: die Anzahl aller Zeilen der Gruppe für die der
> Ausdruck NOT NULL ist.

Nicht was, sondern worin wäre die richtige Formulierung. "Was" würde
bedeuten, das der Ausdruck das Verhalten von COUNT() steuern kann, das
ist jedoch nicht der Fall.


>> Also meine Mysql Version gibt mir bei einer leeren Menge einen Fehler zurück,
>> das ich doch bitte an meiner SQL Syntax arbeiten soll. Zwischen deiner
>> Definition einer leeren Menge und meiner muss ein Unterschied liegen.
>
> Die leere Menge ist was anderes als keine Menge. Für die leere Menge
> gibt COUNT(*) auch brav eine 0 zurück:

Mein Fehler, ich hatte statt NULL gar nichts angegeben und da haut er mir
richtigerweise eine Fehlermeldung um die Ohren.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Hilfe: MySQL startet plötzlichnicht mehr

Axel Schwenke wrote:
> Andreas Scherbaum wrote:
>> Axel Schwenke wrote:
>
>>> Bezüglich des Releasezeitpunktes: diese Änderung betrifft die Reaktion
>>> des MySQL-Servers auf grenzwertiges SQL. Niemand außer QA-Leuten oder
>>> PostgreSQL-Trollen mit Fixierung auf MySQL-Gotchas ;-) schreibt sowas.
>>
>> Stellt sich mir die Frage, wieso ausgerechnet du jedesmal anspringst,
>> wenn jemand über Probleme berichtet.
>
> Du hast schon mal über Probleme berichtet? Zeigen! Der Einstieg des
> Andreas & Andreas Troll-Duos in diesen Thread war mal wieder ein
> typisches Trollposting. Nichts weiter.

Bugreports? Genügend. Für Mysql? Nein. Für DBI mit Mysql und für PHPMyAdmin
schon. Für sonstige Software auch, wenn ich welche finde. Und hör doch
bitte auf, mich jedesmal mit Andreas Kretschmer gleichzusetzen. Er hatte
über etwas berichtet, was ich vor einiger Zeit mal herausgefunden hatte.
Das du die darauffolgende Diskussion dann nutzt, dich dann aber letztendlich
doch mit "typisches Trollposting" herausredest, ist nicht mein Problem.
Ignorier es halt von Anfang an, wenn es dich stört.


> Wenn du tatsächlich ein Problem mit dem neuen Verhalten von COUNT()
> gehabt hättest, dann wäre ein Bugreport oder zumindest eine Nachfrage
> hier die normale Reaktion gewesen.

Sage mal, weisst du überhaupt noch, worum sich diese Diskussion hier
dreht? Oder darf ich dich daran erinnern: es ging darum, das ältere
Versionen von Mysql meiner Ansicht nach ein falsches Verhalten gezeigt
hatten und dies stillschweigend zwischendurch geändert wurde.

Ich habe nirgends behauptet, das ich mit dem neuen Verhalten ein Problem
habe, von daher sehe ich auch keinen Anlass für einen Bugreport. Den
Bugreport über ein fehlendes Changelog kann ich mir hoffentlich sparen,
oder?


>> Soviel zu Minor Releases, oder?
>
> An sich sollten behaviour changes nur dann in Minor Releases
> auftauchen, wenn sie offensichtliche Bugs beheben.
>
> [...]
>
> Aber wie ich bereits schrieb bezieht sich diese Änderung auf SQL-
> Statements, die an sich schon sinnlos sind.

Das bezog sich dann schon darauf, das offensichtlich mehr am Verhalten
geändert wurde als nur die Ausgabe von "select count(1)" richtig zu
stellen. Und dann ist die Frage nach Minor Release berechtigt,
schliesslich ist nicht abzusehen (und nicht erwähnt/dokumentiert),
welche Funktionalität davon noch betroffen ist.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: COUNT()

Thomas Rachel wrote:

>> Aber bei Count(1) stellt die "1" keinen Wert dar, sondern entspricht
>> einem "*", also alle Rows der Menge.
>
> Prinzipiell ja, wie mir nach etwas Nachdenken einleuchtet. Für jedes
> Element der Menge wird festgestellt, ob das Argument NOT NULL ist. Und
> das ist bei 1 ja immer der Fall.

Bei einem Count(*) wird unabhängig von NULL/NOT NULL nur die Anzahl der
Rows der Menge gezählt und dieses Verhalten ist einzigartig.

>> Diese Menge existiert aber nicht.
>
> Das wiederum stimmt nicht - die Anzahl der Rows ist tatsächlich 1,
> nämlich die zurückgegebene - solange keine Tabelle angegeben wurde.

Aber diese Row existiert nur, weil bei Count *immer* eine Row
zurückgeliefert wird, auch bei einer leeren Menge.

> IMHO kann man
>
> SELECT 1;
>
> schreiben als
>
> SELECT a FROM (SELECT 1 AS a) AS t;
>
> wobei die "innere" Tabelle t genau einen Row zurückliefert.

Genau.

> Dasselbe gilt dann auch für
>
> SELECT COUNT(71);

Hier bin ich anderer Meinung :-)

> SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT 22 AS a) AS t;

Dreimal die 1

> und auch
>
> SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT 22 AS a UNION SELECT 33)
> AS t;

Dreimal die 2

> Liefert die innere Tabelle nichts zurück, kommt auch 0 raus:
>
> SELECT COUNT(*),COUNT(a),COUNT(87) FROM (SELECT NULL AS a LIMIT 0) AS t;

Dreimal die 0

Eigentlich ist es eh egal, was zurückkommt, da sowas im Standard SQL
nicht definiert ist. Das Ergebnis könnte also je nach DBMS
unterschiedlich ausschauen, aber zumindest sollte es innerhalb desselben
Systems konsistent das gleiche Ergebnis liefern und entsprechend
dokumentiert sein.

Übrigens auch interessant, wenn "select count(*)" eine 0 liefert und
"select 1" eine Row, was gibt dann ein "select 1, count(*)"?

Kein Wunder, dass sich die Leute beim Standard SQL sowas nicht antun
wollten :-)

Dieter