mysql_affected_rows() Nicht bei Select ?

[Nicole]

Hallo erst mal ;-),

Ich benutze mit Vorliebe und seit Jahren
die Funktion "mysql_affected_rows()" auch
bei select Abfragen.

Nun dürfte das ja laut Manual gar nicht gehen,
aber geht DOCH. ( In allen mysql Versionen ,die
ich beisher nutzte).

Kann mir also jemand erklären, warum das im Widerspruch
mit dem Manual steht, bzw. ob es einen trifftigen Grund
gibt das so nicht zu nutzen ?

Es ist halt einfacher als mysql_num_rows($sql),
oder mysql_fetch_array($sql), auswerten usw.

// also so:
mysql_query("select id from tbl where id='223'");
if(mysql_affected_rows() !=1){$say = "Einfach und gut";}

// oder ungern so
$x = mysql_query("select count(id) from tbl where id='223'");
$y = mysql_fetch_array($x);
if($y['0'] !=1 ){$say = "Einfach mehr Aufwand";}

// Besonders bei vielen Abfragen und Tests ist es halt
// nervig, darum die Frage ;-)

Gruss Nikki

[Tom]

Hello,

nee, denn Datenmanipulation findet bei SELECT nicht statt, hoffentlich nicht.

aber mysql_num_rows($res) gibt es da.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Nicole]

Hallo Tom,
danke für die schnelle Antwort, aber

nee, denn Datenmanipulation findet bei SELECT nicht statt, hoffentlich nicht.

Was meinst du damit ? mysql_affected_rows() geht dennoch
bei select Abfragen , probiers aus.

aber mysql_num_rows($res) gibt es da.

Ja das gibt´s, sollte man aber nicht nutzen, denn
bei vielen Datensätzen leidet die Performance abscheulich.

Ausserdem müsste man auch dann so schreiben:
$sql =mysql_query....
mysql_num_rows($sql)...

Anstatt so:
mysql_query...
mysql_affected_rows()...

Also keine Deklaration !!!

Trotzdem Danke,
Gruss Nikki

[Tom]

Hello,

Hallo Tom,
danke für die schnelle Antwort, aber

nee, denn Datenmanipulation findet bei SELECT nicht statt, hoffentlich nicht.

Was meinst du damit ? mysql_affected_rows() geht dennoch
bei select Abfragen , probiers aus.

Sollte nach einem Select aber 0 ergeben.

aber mysql_num_rows($res) gibt es da.

Ja das gibt´s, sollte man aber nicht nutzen, denn
bei vielen Datensätzen leidet die Performance abscheulich.

Das verstehe ich nicht. Ohne Abfrage (Select) kann man nicht feststellen, wieviele Datensätze von der Filterbedingung betroffen sind. Man kann ja immer noch "select count(*) as z from TABLE where BEDINGUNG ..." benutzen, wennn man nur an der Anzahl inteessiert ist.

so müsste es aussehen:

$res = mysql_query($sql, $con);
$z = mysql_num_rows($res);

mysql_query...
$z= mysql_affected_rows($res);

Also keine Deklaration !!!

was für eine Deklaration? Meinst Du das Resource-Handle?

<cite><http://de.php.net/manual/de/function.mysql-affected-rows.php >
Diese Funktion arbeitet nicht in Verbindung mit SELECT-Anfragen, sondern nur bei Anweisungen, die Datensätze verändern. Um die Anzahl der gelieferten Datensätze einer SELECT-Anfrage zu erhalten, benutzen Sie die Funktion mysql_num_rows().
</cite>

Liebe Grüße aus http://www.braunschweig.de

Tom

[Nicole]

Hallo Tom,

Sollte nach einem Select aber 0 ergeben.

Nein, die Anzahl stimmt, probiers doch wenigsrtens mal
aus, wenn du mir nicht glaubst.

so müsste es aussehen:

$res = mysql_query($sql, $con);
$z = mysql_num_rows($res);

mysql_query...
$z= mysql_affected_rows($res);

Nein, $res kannst du Dir sparen, das ist ja der Sinn daran ;-)

Also keine Deklaration !!!
was für eine Deklaration? Meinst Du das Resource-Handle?

Nein, eben dass ich nicht erst $... schreiben muss
sondern nur mysql_query....
und mysql_affected_rows() // ohne $.....

Thats all.

Gruss Nikki

[Tom]

Hello,

Hallo Tom,

Sollte nach einem Select aber 0 ergeben.

Nein, die Anzahl stimmt, probiers doch wenigsrtens mal
aus, wenn du mir nicht glaubst.

so müsste es aussehen:

$res = mysql_query($sql, $con);
$z = mysql_num_rows($res);

mysql_query...
$z= mysql_affected_rows($res);

Nein, $res kannst du Dir sparen, das ist ja der Sinn daran ;-)

Also keine Deklaration !!!
was für eine Deklaration? Meinst Du das Resource-Handle?

Nein, eben dass ich nicht erst $... schreiben muss
sondern nur mysql_query....
und mysql_affected_rows() // ohne $.....

Wenn "schmutzige Lösungen" funktionieren, werden sie dadurch nicht richtiger. Aber du hast Rech, es müsste mysql_affected_rows($con) heißen. $con ist das Server-Handle der Verbindung und das wird automatsich rausgesucht. Es ist immer die letzte Verbindung, wenn man mehrere Server zur gleichen Zeit (in einem Script) abfragt.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Nicole]

Hallo Tom,
danke für Deine Mühe, aber

1. Hast Du den Sinn meiner Frage nicht verstanden.
Wollte nur wissen warum man das nicht nutzen soll,
und vor allem warum das Manual das so extrem abstreitet.

2. Meine Ausführungen sollten eigentlich klarmachen,
dass ich weiss wovon ich schreibe.

Wenn "schmutzige Lösungen" funktionieren, werden sie dadurch nicht richtiger. Aber du hast Rech, es müsste mysql_affected_rows($con) heißen. $con ist das Server-Handle der Verbindung und das wird automatsich rausgesucht. Es ist immer die letzte Verbindung, wenn man mehrere Server zur gleichen Zeit (in einem Script) abfragt.

Wie ich schon sagte, was zu diesem Thema gechrieben wird
weiss ich selbst. Und ich dachte nicht, dass wenn ich hier
eine Frage stelle erst mal meine Glaubwürdigkeit unter Beweis stellen muss.

Ich brauche Hilfe von Jemanden der sich wirklich auskennt,
Nichts für Ungut, aber wenn ich eine Antwort nicht weiss,
versuche ich nicht mich einzumischen.

Gruss Nikki

[Tom]

Hello,

Ich brauche Hilfe von Jemanden der sich wirklich auskennt,
Nichts für Ungut, aber wenn ich eine Antwort nicht weiss,
versuche ich nicht mich einzumischen.

Oh, ich bitte um Entschuldigung. Ich wusste nicht, dass Du PHP erfunden hast. Sooo genau kann ich es natürlich nicht wissen. Ich werde versuche, auf Deine Postings in Zukunft nicht mehr zu reagiern und werde es den Anderen auch sagen, damit sie dich nicht verärgern.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Frechheit vom TOM]

Bisher war ich höflich,
aber wenn Jemand so unverschämt ist und den Titel
meiner Frage in der Form verändert Schreit das nach klaren
Worten.

"DEINE INKOMETENZ IST ERSCHRECKEND".

Aber nicht Jeder ist Kritikfähig.

[töbi]

Bisher war ich höflich,

Sei höflicher!
Wenn man sich die Mühe nimmt sich mit deinen Problemen zu beschäftigen erwartet man nicht solche Worte wie du vorhin zu Tom.

aber wenn Jemand so unverschämt ist und den Titel
meiner Frage in der Form verändert Schreit das nach klaren
Worten.

Wieso? Der Titel sollte wertvolle Informationen zum Inhalt liefern dieser hier ist sehr treffend!

"DEINE INKOMETENZ IST ERSCHRECKEND".

blabla..

Aber nicht Jeder ist Kritikfähig.

Das ist kritik.

[Chris]

Bisher war ich höflich,
aber wenn Jemand so unverschämt ist und den Titel
meiner Frage in der Form verändert Schreit das nach klaren
Worten.

"DEINE INKOMETENZ IST ERSCHRECKEND".

Aber nicht Jeder ist Kritikfähig.

@tom:
Das ist wirklich frech von Dir, dieser agressiven Emanze einfach mehr als einmal zu antworten, und dich so runtermachen zu lassen. Wir hatten doch vereinbart, das wir diese Flintenweiber genauso behandeln wollen, wie die pubertären Jünglinge, die hier nur ihre persönlichen Grenzen ermitteln wollen, ohne jegliche Diskussionsfähigkeit zu besitzen. Also geh nochmal in dich ;-)

@nicole:
Du solltest Dir schnellstens einen neuen Nickname suchen und nochmal ganz von vorne anfangen.

LG
Chris

[Tom]

Hello,

@nicole:
Du solltest Dir schnellstens einen neuen Nickname suchen und nochmal ganz von vorne anfangen.

hat die doch schon. Sie heißt doch ab jetzt "Frechheit vom TOM".
Also SIE sit die Frechheit von mir. Allerdings habe ich bisher wissentlich nur eine Tochter. Kann ich da jetzt wegen "Tochterschaft in fremdem Namen ohne Auftrag" abmahnen, oder muss das meine Tochter tun?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Bio]

Sup!

Wer in seinem Logo einen Vibrator mit Netzspannungsversorgung in bananengelb hat, der hat sich sowieso und ueberhaupt als gaaaanz ueeeebler... ehm... auf jeden Fall... entlarvt!

Gruesse,

Bio

[Tom]

Hello Bio,

Wer in seinem Logo einen Vibrator mit Netzspannungsversorgung in bananengelb hat, der hat sich sowieso und ueberhaupt als gaaaanz ueeeebler... ehm... auf jeden Fall... entlarvt!

Ich geb ja zu, dass ich Frauenbewegungen schon immer gut fand. Und die kleinen Kröten sind meistens die besseren Sportpartner... *ggg*

Aber ist unsere PosterIn überhaupt eine Frau oder ein verkappter hormonfehlgesteuerter Kerl mit Frühlingsambitionen?

Liebe Grüße aus http://www.braunschweig.de

Tom

[WebViper]

Hi,

Bisher war ich höflich,

Genau...

aber wenn Jemand so unverschämt ist und den Titel
meiner Frage in der Form verändert Schreit das nach klaren
Worten.

Ich bin der meinung er hat den Titel nur berichtigt...

"DEINE INKOMETENZ IST ERSCHRECKEND".

und was ist dann der ausdruck fuer deine? Ich halte Tom fuer weit kompetenter als dich... uebrigens... inkom_P_etenz... nur soviel du deiner... ;))

Aber nicht Jeder ist Kritikfähig.

Richtig... Und zu denen gehoerst eindeutig du...

mfg
-WebViper-

[Christian Kruse]

Hallo Nicole,

2. Meine Ausführungen sollten eigentlich klarmachen,
   dass ich weiss wovon ich schreibe.

Das wage ich zu bestreiten. Wenn dir nicht klar ist, dass ein "SELECT feld" mit
möglicherweise 100000 Reihen mehr Performance und Ressourcen frisst als ein "SELECT
COUNT(feld)", sorry, aber dann weisst du definitiv nicht, wovon du redest.

Grüße,
 CK

[Stefan]

Hi Nikki,

Hallo Tom,
danke für Deine Mühe, aber

1. Hast Du den Sinn meiner Frage nicht verstanden.
   Wollte nur wissen warum man das nicht nutzen soll,
   und vor allem warum das Manual das so extrem abstreitet.

Nikki, ich glaube _DU_ hast den Sinn von sauberer Programmierung einfach nicht kapiert. Du schleuderst hier eine Frage in das Forum und bei jeglicher gerechtfertigten Kritik, dass man nicht gegen ein Manual arbeiten soll, weil sich eine undokumentierte Funktion von jetzt auf dann eben ändern kann und dann nicht mehr funktioniert, mit einem Pfal in den Boden rammst, lässt den Anschein aufkommen, dass Du den logischen Hintergedanken der Antwort(en) gar nicht erst kapiert hast.
Nur weil etwas geht, muss es eben nicht richtig sein. Wenn Du lernen willst zu Programmerieren, dann solltest Du es auch richtig machen. Und wenn Du Fragen hast, dann solltest Du auch qualifizierte Antworten akzeptieren. Es ist nun mal Fakt, dass mysql_num_rows() für SELECT Abfragen zu nutzen ist und ich kenne keine Seite, die an dieser Stelle mit mysql_affected_rows() arbeitet. Ein Grund hierfür könnte auch sein, dass, wenn Du erst ein UPDATE durchführst und dann ein SELECT, der Wert von mysql_affected_rows() beim SELECT nicht mehr aktualisiert wird (werden sollte). Wer weiß, ob diese Funktion in der nächsten Version endlich genau dies tut!?

2. Meine Ausführungen sollten eigentlich klarmachen,
   dass ich weiss wovon ich schreibe.

Echt?! Ich glaube eher, dass Du ein wenig überzeugt von die selbst bist und nun meinst, uns alle davon zu überzeugen, dass wir uns Dir anpassen sollen und alle mysql_affected_rows() anwenden _müssen_. Weißt Du was: Ich geb ein *piep* auf Deine nicht qualifizierten Aussagen, die Dir allerhöchstens den Job als "Kaffeeholerin" in einer Programmierabteilung vermitteln.

Wenn "schmutzige Lösungen" funktionieren, werden sie dadurch nicht richtiger. Aber du hast Rech, es müsste mysql_affected_rows($con) heißen. $con ist das Server-Handle der Verbindung und das wird automatsich rausgesucht. Es ist immer die letzte Verbindung, wenn man mehrere Server zur gleichen Zeit (in einem Script) abfragt.

Wie ich schon sagte, was zu diesem Thema gechrieben wird
weiss ich selbst. Und ich dachte nicht, dass wenn ich hier
eine Frage stelle erst mal meine Glaubwürdigkeit unter Beweis stellen muss.

Das ist Dir aber auch eindrucksvoll _misslungen_! Deine Glaubwürdigkeit hättest Du mit etwas Einsehen bewahren können, allerdings nicht mit solchen Antworten. Du klingst mir eher etwas frustriert und meinst Deine schlechte Laune auf andere ausbreiten zu müssen. Naja, wie Du denkst, aber ich halte Dich für eine sehr arme Person!

Ich brauche Hilfe von Jemanden der sich wirklich auskennt,
Nichts für Ungut, aber wenn ich eine Antwort nicht weiss,
versuche ich nicht mich einzumischen.

Einfach eine Frechheit! Deine Antwort wurde mehreremals beantwortet, aber Du und Deine Sturrheit seit ein unzertrennliches Paar. Schön wenn man vor einer Wand sitzt und denkt es sei der Horizont des Lebens. Vielleicht kaufst Du Dir mal einen Spiegel oder drehst Dich einfach mal um, dann wirst Du sehen, dass es noch viel weiter geht, als nur 5cm nach vorne :P

Gruss
Stefan

[Sven Rautenberg]

Moin!

Es ist halt einfacher als mysql_num_rows($sql),
oder mysql_fetch_array($sql), auswerten usw.

// also so:
mysql_query("select id from tbl where id='223'");
if(mysql_affected_rows() !=1){$say = "Einfach und gut";}

Und woher willst du wissen, ob dein Query funktioniert hat? Fehlerbehandlung etc. fehlen hier komplett! Ist ja grausam, sowas!

Du kannst auf die Auswertung der Ressoure, die von mysql_query zurückkommt, nicht verzichten. Die ist im Fehlerfall nämlich FALSE, und das muß man abfangen, ansonsten landet man bei unschönen Fehlerabbrüchen.

Und wenn du ein SELECT machst, dann willst du ja sowieso den Inhalt dieser Abfrage wissen - und den kriegst du ebenfalls nur mit Ressource-Handle, nicht ohne.

Und wenn du das Ressource-Handle sowieso hast, kannst du auch einfach

$res = mysql_query();
if (mysql_num_rows($res) != 1) ...

machen.

Du sprachst vom gewaltigen Performance-Verlust mit mysql_num_rows bei großen Abfragen? Bitte nimm mal Kontakt zur Realität auf! Du fragst in deinem Beispiel genau eine Zeile ab. Das ist keine "große" Abfrage.

Außerdem: mysql_query kopiert die gesamten DB-Ergebnisse in einen PHP-Zwischenspeicher. _Das_ ist bei großen Abfragen die Performancebremse. Auf ein abgefragtes Ergebnis mal eben mysql_num_rows() anzuwenden ist dagegen ein Kinderspiel.

Und wenn du mysql_unbuffered_query verwendest, um die Performancebremse durch insbesondere den Speicherverbrauch bei großen Abfragen zu umgehen, mußt du sowieso wissen, was du tust, und kannst nicht mehr mit der Begründung "Das ist aber einfacher" kommen.

- Sven Rautenberg

[Nicole]

Du sprachst vom gewaltigen Performance-Verlust mit mysql_num_rows bei großen Abfragen? Bitte nimm mal Kontakt zur Realität auf! Du fragst in deinem Beispiel genau eine Zeile ab. Das ist keine "große" Abfrage.

Hallo Sven, kenne eigentlich kompetentere Antworten von Dir.

Mein Beispiel fragt nur eine Zeile ab ?
Woher weisst du das ?
Die Id 223 kann 100.000 mal vorkommen wenn nicht unique, Richtig ?

Im Übrigen war das nur ein Beispiel, mach doch mal ein Counterscript
mit Statisken mit mysql_num_rows(), lächerlich so was.

Also ich gehe mal davon aus auch du weisst nicht warum
man mysql_affected_rows nicht nehmen soll, obwohl es geht ?

Und sag jetzt nicht, weil es geschrieben steht...

Gruss Nikki.

ps. Erst denken dann kritisieren, sonst geht der
Schuss nach hinten loss.

[Sven Rautenberg]

Moin!

Hallo Sven, kenne eigentlich kompetentere Antworten von Dir.

Willst du diesen Thread herunterbrechen auf eine "Frage der Kompetenz"? Scheint im anderen Zweig ja so zu sein.

Mein Beispiel fragt nur eine Zeile ab ?
Woher weisst du das ?
Die Id 223 kann 100.000 mal vorkommen wenn nicht unique, Richtig ?

Richtig, aber dagegen sprechen zwei Dinge:
1. Eine Spalte "ID" ist in aller Regel unique, ansonsten würde man sie nicht "ID" nennen.
2. Wenn du eine Non-unique-Spalte abfragen und tausende Ergebniszeilen erwarten würdest, würdest du sicher andere Dinge mit dem Ergebnis anstellen, als einfach nur auf "Anzahl der Spalten != 1" zu prüfen. Denn was anderes als das DB-Ergebnis wegwerfen tust du ja nicht, wenn du die Ressource-ID nicht abspeicherst, um dann darauf zuzugreifen.

Im Übrigen war das nur ein Beispiel, mach doch mal ein Counterscript
mit Statisken mit mysql_num_rows(), lächerlich so was.

Für die Wahl deines Beispiels bist du natürlich selbst verantwortlich. Wenn das Beispiel schlecht war: Wähle ein besseres.

Außerdem: Wenn ich Statistiken aus einer DB wissen will, in der hinreichend viele Datensätze sind (hinreichend bedeutet für mich durchaus ab 2 Stück, je nach Tagestemperatur), dann werde ich mit Sicherheit weder mysql_num_rows() noch mysql_affected_rows() verwenden, sondern mit SELECT, COUNT(), GROUP BY sowie diversen anderen Aggregatsfunktionen genau die Information performant (und mit Indexnutzung) von der Datenbank abfragen, die ich brauche. Ein simples "SELECT COUNT(*) FROM tabelle" ist von der Performance her jeglichem "SELECT spalte FROM tabelle" plus mysql_affected_rows() überlegen.

Wenn ich die Zahl der abgefragten Datensätze aus der DB wissen _und_ weiterverarbeiten will, werde ich mysql_num_rows() in Verbindung mit mysql_query() verwenden. Üblicherweise aber interessiert mich die Zahl der Datensätze absolut nicht, ich verwende einfach einen nach dem anderen, solange welche aus dem Zwischenpuffer kommen. Das bedeutet, dass bei wirklich großen Ergebnissätzen, bei denen die Anzahl zu wissen eine Rolle spielt, tatsächlich zwei Querys an die DB gehen: Einer zum Durchzählen, und ein mysql_unbuffered_query().

Also ich gehe mal davon aus auch du weisst nicht warum
man mysql_affected_rows nicht nehmen soll, obwohl es geht ?

Und sag jetzt nicht, weil es geschrieben steht...

Ich frage mich, woher du deine Annahmen hast. Sowohl die, dass mysql_affected_rows() böse sein soll, noch die, dass es nicht funktionieren soll.

ps. Erst denken dann kritisieren, sonst geht der
Schuss nach hinten loss.

Ich habe das kritisiert, gegen das du dich in deiner Antwort gar nicht gewendet hast. Nämlich die mangelnde Fehlerbehandlung. Und die etwas abstruse Argumentation hinsichtlich Performance.

Die Dokumentation von MySQL sagt jedenfalls: "Bei SELECT funktioniert mysql_affected_rows() wie mysql_num_rows()." Damit wäre dein Performanceargument hinfällig, weil: Wenn es gleich funktioniert, warum sollte das eine dann superschnell und das andere arschlahm sein?

Aber nur wenn man mysql_store_result() (der MySQL-API) benutzt, wird tatsächlich danach sofort die Anzahl der Ergebniszeilen zurückgegeben, ansonsten erhält man das Ergebnis erst nach Abfrage aller Ergebniszeilen mit mysql_use_result() (und dann hätte man auch einfach selbst mitzählen können).

Bevor du also irgendwelche explosivbeschleunigte Masseteilchen in unintendierte Richtungen losgehen siehst, solltest du sicher gehen, dass du nicht in der Flugbahn derselben stehst.

Oder kurz: Wer lesen kann, ist klar im Vorteil. Man muß aber auch wissen, wo. :)

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

Die Dokumentation von MySQL sagt jedenfalls: "Bei SELECT funktioniert mysql_affected_rows()
wie mysql_num_rows()." Damit wäre dein Performanceargument hinfällig, weil: Wenn es gleich
funktioniert, warum sollte das eine dann superschnell und das andere arschlahm sein?

In diesem Fall ist aber ein Wrapper um die MySQL-API gelegt. Und da ist die PHP-Doku
ausschlaggebend. Und die sagt: nutze mysql_affected_rows() nicht für SELECT-Statements. Und
wenn das da steht, sollte man sich auch daran halten. Aus oben beschriebenen Gründen: das
Verhalten des PHP-Wrappers mysql_affected_rows() ist nicht definiert. Es kann heute so
aussehen, aber morgen schon ganz anders.

Im Moment (PHP 4.3.4) ist PHPs mysql_affected_rows() nur eine Kapselung des
mysql_affected_rows() aus der MySQL-Bibliothek. Das kann sich jedoch auch jederzeit
ändern.

Grüße,
 CK

[Christian Kruse]

Hallo Nicole,

Kann mir also jemand erklären, warum das im Widerspruch
mit dem Manual steht, bzw. ob es einen trifftigen Grund
gibt das so nicht zu nutzen ?

Es ist nicht definiert. Mag sein, dass es jetzt geht. Morgen bereits ist es
möglich, dass es nicht mehr geht.

Es ist halt einfacher als mysql_num_rows($sql),
oder mysql_fetch_array($sql), auswerten usw.

Statt Tippfaulheit walten zu lassen, solltest du mal ein paar Performance-Überlegungen
anstreben. Denn...

// also so:
mysql_query("select id from tbl where id='223'");
if(mysql_affected_rows() !=1){$say = "Einfach und gut";}

Hier ist dein Resultset in einem von dir beschriebenen Fall etwa 100000 Zeilen gross. Und
diese Daten müssen alle vom MySQL-Server serialisiert, durch den Socket geschickt und vom
PHP-Script abgeholt werden.

// oder ungern so
$x = mysql_query("select count(id) from tbl where id='223'");
$y = mysql_fetch_array($x);
if($y['0'] !=1 ){$say = "Einfach mehr Aufwand";}

Hier dagegen ist dein Resultset maximal eine Zeile gross. Es ist also, gelinde gesagt,
idiotisch, ein 'SELECT feld' zu machen, wenn man nur die Anzahl der Datensätze wissen
will.

Grüße,
 CK