Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat

[Martina]

mysql_query("DELETE FROM ........");

Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat?Ichgehe zwar davon aus, aber wenn die besagte Zeile nicht da ist, muss ja irgendwie ein Fehler kommen?

Martina

[ChrisB]

Hi,

mysql_query("DELETE FROM ........");

Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat?

Lese bitte im Handbuch zu mysql_query nach, da steht es beschrieben.

MfG ChrisB

[Fred Furunkelstein]

Hi,

mysql_query("DELETE FROM ........");

Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat?

Lese bitte im Handbuch zu mysql_query nach, da steht es beschrieben.

ChrisB hat sich mal wieder nur unglücklich ausgedrückt. Er wollte sicherlich helfen statt zu meckern.

mysql_affected_rows() liefert Dir die Anzahl der betroffenen Datensätze bei INSERT, UPDATE und DELETE.

Danach hast Du gesucht.

Einen Fehler oder die Anzahl betroffener Datensätze kannst Du Dir so anzeigen lassen:

  
$DBV=[link:http://de3.php.net/manual/de/function.mysql-pconnect.php@title=mysql_pconnect(...)]; // $DBV=Verbindungskennung  
$sql="DELETE ...";  
$result=[link:http://de3.php.net/manual/de/function.mysql-query.php@title=mysql_query($sql, $DBV)]; // wirft eventuell einen Fehler  
if (false===$result) {  
        echo [link:http://de3.php.net/manual/de/function.mysql-error.php@title=mysql_error($DBV)] . "<pre>$sql</pre>\n"; // Sehr hilfreich beim Entwickeln nicht aber auf Produktivservern!  
} else {  
        echo [link:http://de3.php.net/manual/de/function.mysql-affected-rows.php@title=mysql_affected_rows($DBV)]. " Datensätze gelöscht.";  
}

Das Handbuch:
"Nur für SELECT, EXPLAIN, SHOW oder DESCRIBE Anweisungen liefert mysql_query() eine Ressourcen-Kennung oder FALSE, falls die Anfrage nicht korrekt ausgeführt wurde."

Ich, klarstellend:
"Das FALSE kommt aber bei jedem (Syntax- oder Struktur-)Fehler."

Fred

[Sven Rautenberg]

Moin!

$DBV=mysql_pconnect(...); // $DBV=Verbindungskennung

Verwende nie pconnect(), wenn du die Folgen nicht abschätzen kannst.

- Sven Rautenberg

[Fred Furunkelstein]

Tach! Post!

Moin!
Verwende nie pconnect(), wenn du die Folgen nicht abschätzen kannst.

• Sven Rautenberg

Verwende stets mysql_pconnect() wenn Du es nach einer Prüfung der Umstände für richtig erachtest.

Fred Furunkelstein

mysql_pconnect() verhält sich sehr ähnlich zu mysql_connect(), weist aber zwei wesentliche Unterschiede auf.

Erstens: vor dem Verbindungsaufbau wird zunächst versucht eine offene (persistente) Verbindung zum gleichen Host, mit dem gleichen Benutzernamen und Benutzerkennwort zu finden. Wenn das gelingt, wird die Verbindungskennung dieser Verbindung zurückgeliefert anstatt eine neue Verbindung aufzubauen.

Zweitens: die Verbindung zum SQL Server wird beim Beenden des PHP-Skripts nicht geschlossen. Sie bleibt zur zukünftigen Verwendung bestehen. (mysql_close() schließt keine von mysql_pconnect() geöffneten Verbindungen).

Das Handbuch

[Sven Rautenberg]

Moin!

Tach! Post!

Moin!
Verwende nie pconnect(), wenn du die Folgen nicht abschätzen kannst.

• Sven Rautenberg

Verwende stets mysql_pconnect() wenn Du es nach einer Prüfung der Umstände für richtig erachtest.

Fred Furunkelstein

mysql_pconnect() verhält sich sehr ähnlich zu mysql_connect(), weist aber zwei wesentliche Unterschiede auf.

Erstens: vor dem Verbindungsaufbau wird zunächst versucht eine offene (persistente) Verbindung zum gleichen Host, mit dem gleichen Benutzernamen und Benutzerkennwort zu finden. Wenn das gelingt, wird die Verbindungskennung dieser Verbindung zurückgeliefert anstatt eine neue Verbindung aufzubauen.

Zweitens: die Verbindung zum SQL Server wird beim Beenden des PHP-Skripts nicht geschlossen. Sie bleibt zur zukünftigen Verwendung bestehen. (mysql_close() schließt keine von mysql_pconnect() geöffneten Verbindungen).

Das Handbuch

Verwende mysql_pconnect() nur, wenn du sichergestellt hast, dass dein Datenbankserver für alle anfallenden persistenten DB-Connections zusammen ausreichend Connection-Handles anbieten kann - andernfalls schießt man sich heftigst ins Knie.

Und die Performance-Gewinne sind ohnehin nicht so riesig - für den normalen Gebrauch irrelevant, für etliche Szenarien bei Hostern wirkt pconnect() sowieso nicht, wenn PHP nicht als Apache-Modul läuft.

- Sven Rautenberg

[Fred Furunkelstein]

Verwende mysql_pconnect() nur, wenn du sichergestellt hast, dass dein Datenbankserver für alle anfallenden persistenten DB-Connections zusammen ausreichend Connection-Handles anbieten kann - andernfalls schießt man sich heftigst ins Knie.

Naja... mysql_pconnect() ist nicht ohne Grund nach(!) mysql_connect() eingeführt worden.

Auf Servern mit einer hohen Zahl von gleichzeitigen HTTP-Verbindungen (= hohe Zahl parallel ausgeführter Skripte mit Verbindungen zu gleichen MySQL-Server für gleichen Benutzer) kann mysql_connect auch den Effekt ("error: to many connections") haben - während dieser dann nicht aufträte, wenn in der Situation mysql_pconnect benutzt würde.

Das Ganze ist also eine Einzelfallentscheidung. Strato- Kunden oder solche von Hostern mit vielen Kunden auf einem Server (= verschiedene Userkennungen) sollten mysql_pconnect eher nicht einsetzen. Hat man aber wenige Kunden auf dem Datenbankserver und also viele Skripte (oder Skriptaufrufe)  mit gleichen Benutzerkennungen ist mysql_pconnect klar im Vorteil: Die Frage der Performance beantwortet sich nämlich sehr wahrscheinlich ganz anders wenn man an einen entfernten statt einen lokalen MySQL-Dämon und an verschlüsselte Verbindungen e.t.c. denkt.

Das mit dem Modul steht im Handbuch - ist aber auch logisch weil der Skriptinterpreter PHP als CGI oder am Prompt ausgeführt natürlich beim Beenden nach der Skriptausführung auch alle Datenbankverbindungen schließt. Wie sollte er dann die Verbindungen offen halten?

Fred

[dedlfix]

Tach!

Das Ganze ist also eine Einzelfallentscheidung. Strato- Kunden oder solche von Hostern mit vielen Kunden auf einem Server (= verschiedene Userkennungen) sollten mysql_pconnect eher nicht einsetzen.

Wie sieht denn die aktuelle Situation bei den Massenhostern aus? Man kann ja FCGI/suEXEC nehmen und die Scripte werden alle unter der Kennung des jeweiligen Kunden ausgeführt. Das belastet zwar den Server mehr, ist aber auch sicherer für Kunden und Hoster und komfortabler für den Kunden. Oder man lässt PHP als Apache-Modul laufen, was aber nur unter der Kennung des Servers geht. Damit die User etwas abgeschirmt sind, setzt man die Krücke namens Safe Mode ein. Scripte gehören dem jeweiligen User, ausgeführt werden sie aber unter der Kennung des Apachen, und PHP versucht da ein bisschen aufzupassen, dass da keiner was dummes mit den Dateien der anderen anstellt. Das bereitet auch einiges Ungemach, weil man diese Besitzverhältnisse beachten muss. Der Safe Mode ist schon seit langem seitens PHP auf der Abschussliste. Und ich habe hier auch schon ewig keine Probleme mehr gelesen, bei denen sich der Safe Mode als Ursache herausstellte. Ist er also zumindest bei der Masse der Hoster ausgestorben? Wenn ja, würde das darauf hindeuten, dass die Hoster PHP nur noch in irgendeiner Form von CGI laufen lassen.

Dann bliebe als Einsatzgebiet für die Modul-Version von PHP nur noch der eigene Server übrig. Und selbst da sollte man beim Konfigurieren bedenken, wenn man unterschiedliche Projekte hostet, ob man dann nicht lieber auch die Sicherheit vorgehen lässt und auf FCGI/suEXEC setzt. Der Rest (wenn ich nicht was übersehen habe) sind dann Projekte, die aufgrund ihrer Größe mindestens einen Server allein benötigen. Dann sollte der Administrator von selbst wissen oder sich darüber informieren können, wann/ob er mysql_pconnect() verwenden kann.

Was anderes als mysql_connect() (ohne p) wird nach dieser Theorie den meisten gar nicht zur Verfügung stehen. Zudem werden die Projekte eher so klein sein, dass sie selbst keine Vorteile der p-Variante zu spüren bekommen. Alles andere sind Probleme, über die sich der Hoster einen Kopf machen muss.

dedlfix.

[Sven Rautenberg]

Moin!

Verwende mysql_pconnect() nur, wenn du sichergestellt hast, dass dein Datenbankserver für alle anfallenden persistenten DB-Connections zusammen ausreichend Connection-Handles anbieten kann - andernfalls schießt man sich heftigst ins Knie.

Naja... mysql_pconnect() ist nicht ohne Grund nach(!) mysql_connect() eingeführt worden.

Sicherlich mit der Idee von mehr Performance. Allerdings ist anzumerken, dass MySQL nun ausgerechnet die Datenbank ist, die sowieso recht wenig Zeit beim Connect verbrät, im Gegensatz zu anderen Varianten.

Auf Servern mit einer hohen Zahl von gleichzeitigen HTTP-Verbindungen (= hohe Zahl parallel ausgeführter Skripte mit Verbindungen zu gleichen MySQL-Server für gleichen Benutzer) kann mysql_connect auch den Effekt ("error: to many connections") haben - während dieser dann nicht aufträte, wenn in der Situation mysql_pconnect benutzt würde.

Allerdings kann man die benötigte Anzahl von durch connect() erzeugten Verbindungen sehr einfach abschätzen: Anzahl der maximal erlaubten Apache-Threads oder -Prozesse multipliziert mit 1. Denn wenn der Apache keine weiteren Prozesse erlaubt, scheitern die Zugriffe am Apachen, und nicht an der Datenbank. Das ist im Ergebnis genauso doof, aber insgesamt besser handhabbar.

Im Gegensatz dazu ergibt sich die Anzahl von durch pconnect() erzeugten Verbindungen durch die Anzahl der maximalen Apache-Prozesse, multipliziert mit der Anzahl in allen PHP-Skripten verwendeten Connection-Details (Kombination aus Server, User und Passwort).

Die klassische Kombination aus Readonly-DB-User plus Admin-User erzeugt auf dem Apachen langfristig die doppelte Anzahl an dauerhaft benutzten DB-Connections im Vergleich zu connect().

Das Ganze ist also eine Einzelfallentscheidung.

Sehr richtig. Im Einzelfall kann man sich unter Abwägung aller Randbedingungen auch mal für pconnect() entscheiden, wenn man die Seiteneffekte kennt und akzeptiert.

Grundsätzlich würde ich dagegen immer nur mit connect() arbeiten und keine persistenten Connections aufbauen.

Strato- Kunden oder solche von Hostern mit vielen Kunden auf einem Server (= verschiedene Userkennungen) sollten mysql_pconnect eher nicht einsetzen. Hat man aber wenige Kunden auf dem Datenbankserver und also viele Skripte (oder Skriptaufrufe)  mit gleichen Benutzerkennungen ist mysql_pconnect klar im Vorteil: Die Frage der Performance beantwortet sich nämlich sehr wahrscheinlich ganz anders wenn man an einen entfernten statt einen lokalen MySQL-Dämon und an verschlüsselte Verbindungen e.t.c. denkt.

Das mit dem Modul steht im Handbuch - ist aber auch logisch weil der Skriptinterpreter PHP als CGI oder am Prompt ausgeführt natürlich beim Beenden nach der Skriptausführung auch alle Datenbankverbindungen schließt. Wie sollte er dann die Verbindungen offen halten?

Dein Szenario mal zusammengefasst: Im Prinzip braucht man keine persistenten Verbindungen. Bei den Massenhostern wirkt pconnect() sowieso nur wie connect(). Bei Szenarien mit vielen DB-Usern ist pconnect() in der Gefahr, die Datenbankserver zu überlasten.

Und auch das Performance-Argument ist von dir nicht mit belastbaren Zahlen belegt. Wieviel würde man mit pconnect() unter idealen Bedingungen denn wirklich gewinnen?

Darüber hinaus wäre noch zu kritisieren, dass du grundsätzlich das veraltete Modul "mysql" anwendest, und nicht "mysqli". :P

- Sven Rautenberg

[Fred Furunkelstein 2011]

Tach Sven1

Dein Szenario mal zusammengefasst: Im Prinzip braucht man keine persistenten Verbindungen. Bei den Massenhostern wirkt pconnect() sowieso nur wie connect(). Bei Szenarien mit vielen DB-Usern ist pconnect() in der Gefahr, die Datenbankserver zu überlasten.

Da hast Du Recht, was auch gilt wenn Du für meinen Geschmack die negativen Apsekte ein wenig überbetonst. Du hast Übrigens vergesen, dass bei vielen Massenhostern (und auch sonst) die Zahl der Webserver nicht mit der der Datenbankserver übereinstimmt.

Und auch das Performance-Argument ist von dir nicht mit belastbaren Zahlen belegt. Wieviel würde man mit pconnect() unter idealen Bedingungen denn wirklich gewinnen?

Das hängt von den "idealen Bedingungen" ab. Ich vermute bei entfernten Servern mit bescheidenen Ping-Raten, womöglich noch virtuellen Netzen oder Verschlüsselung dürfte der Gewinn sehr gut spürbar werden.

Eines sollte ich noch erwähnen, manche Poster auf PHP .net behaupten, es gäbe bei mysql_pconnect() auch Probleme mit offenen Transaktionen und temporären Tabellen. Hier muss man also sehr sorgfältig programmieren.

Du hast also nochmals recht, empfehlen wir den Laien lieber mysql_connect oder das neuere mysqli_connect() / mysqli_init() / mysqli::__construct() - und hofen wir damit nicht noch mehr Verwirrung zu stiften...

Fred

[Texter mit x]

Verwende nie pconnect(), wenn du die Folgen nicht abschätzen kannst.

• Sven Rautenberg

Verwende stets mysql_pconnect() wenn Du es nach einer Prüfung der Umstände für richtig erachtest.

Und Du hast auch nur die wage Hoffnung, daß Martina dazu qualifiziert ist?

[Fred Furunkelstein 2011]

Verwende nie pconnect(), wenn du die Folgen nicht abschätzen kannst.

• Sven Rautenberg

Verwende stets mysql_pconnect() wenn Du es nach einer Prüfung der Umstände für richtig erachtest.

Und Du hast auch nur die wage Hoffnung, daß Martina dazu qualifiziert ist?

Ich habe wenig Lust dazu mich in einem Forum über die Qualifikation der Fragenden auszulassen, werde mich also weder positiv noch negativ äußern.

Fred

[Texter mit x]

Ich habe wenig Lust dazu mich in einem Forum über die Qualifikation der Fragenden auszulassen, werde mich also weder positiv noch negativ äußern.

Sich dazu zu äußern ist unnötig, aber offensichtliches bei der Antwort zu berücksichtigen ist angebracht.

[Fred Furunkelstein 2011]

Sich dazu zu äußern ist unnötig, aber offensichtliches bei der Antwort zu berücksichtigen ist angebracht.

Für mich ist offensichtlich dass das Problem "mysql_pconnect oder mysql_connect" ganz einfach vom Hoster zu lösen ist. Im Massenhosting (von ganz wenigen Fällen abgesehen, in denen es aber professionelle Admins geben wird, kann nur dieses kann das Problem verursachen) ist es durchaus üblich Funktionen zu verbieten [manche verbieten sogar php_info()] oder sogar (und das wäre optimal PHP aus dem Quelltext zu installieren und dabei dafür zu sorgen, das mysql_pconnect lediglich ein alias von mysql_connect ist. Das ist ja dann auch nicht weiter schädlich, die Parameter sind die gleichen und die Frage, wie mysql_close() dazu kommt die Verbindung zu schließen, kann der Support beantworten.

[ChrisB]

Hi,

ChrisB hat sich mal wieder nur unglücklich ausgedrückt. Er wollte sicherlich helfen statt zu meckern.

Ich wollte, wie meistens, zu eigenständigem informieren und arbeiten anregen.

Arschkriecherisch die vorgekaute Fertiglösung zu präsentieren überlasse ich dir, mein Schleimschneckchen.

/EOD 4 me.

MfG ChrisB

[Fred Furunkelstein]

Arschkriecherisch die vorgekaute Fertiglösung zu präsentieren überlasse ich dir, mein Schleimschneckchen.

Ich finde es sehr schön dass Du heute so gut gelaunt bist und auf konstruktive Kritik so gar sachlich reagierst.

Fred

[EKKi]

Mahlzeit Fred Furunkelstein,

Arschkriecherisch die vorgekaute Fertiglösung zu präsentieren überlasse ich dir, mein Schleimschneckchen.

Ich finde es sehr schön dass Du heute so gut gelaunt bist und auf konstruktive Kritik so gar sachlich reagierst.

Fred

Oooch, fastix ...

MfG,
EKKi

[dedlfix]

Tach!

Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat?Ichgehe zwar davon aus, aber wenn die besagte Zeile nicht da ist, muss ja irgendwie ein Fehler kommen?

Welche besagte Zeile? Wenn ein DELETE nichts löschen konnte ist das ebensowenig ein Fehler wie ein SELECT, das nichts gefunden hat. Wie du an Informationen zur Anzahl der gelöschten Zeilen kommst, steht im PHP-Handbuch auf der Seite von mysql_query().

dedlfix.

[Martina]

Das ist meine ganze Zeile:

  
mysql_query("DELETE FROM tabelle1 WHERE id='1'");	  

Wenn die ID 1 da ist wird sie gelöscht. Aber ich schaffe auch nicht mir dem Handbuch mir auszugeben ob die löschung stattgefunden hat oder nicht!

Kann mir doch jemand weiterhelfen

Martina

[Fred Furunkelstein]

Moin!

Kann mir doch jemand weiterhelfen

Aber ja doch. Die Antworten von dedlfix und ChrisB sind nur manchmal etwas merkwürdig. Aber die sind nicht die einzigen die hier antworten.

RTFM könnte man schließlich fast immer antworten. Nur ist es halt oft NICHT HILFREICH.

fred

[dedlfix]

Tach!

Wenn die ID 1 da ist wird sie gelöscht. Aber ich schaffe auch nicht mir dem Handbuch mir auszugeben ob die löschung stattgefunden hat oder nicht!

Was hast du probiert und woran bist du gescheitert?

Kann mir doch jemand weiterhelfen

Wenn du dein Problem genauer beschreiben würdest, könnte man auch genauer darauf eingehen, ohne wild herumraten zu müssen.

dedlfix.

[Fred Furunkelstein]

Wie frage ich ab ob mein mysql_query DELETE auch gelöscht hat?Ichgehe zwar davon aus, aber wenn die besagte Zeile nicht da ist, muss ja irgendwie ein Fehler kommen?

Wenn die ID 1 da ist wird sie gelöscht. Aber ich schaffe auch nicht mir dem Handbuch mir auszugeben ob die löschung stattgefunden hat oder nicht!

Was hast du probiert und woran bist du gescheitert?

Ist doch offensichtlich. Martina will einfach wissen ob etwas gelöscht wurde. Die MySQL-Syntax ist der zweimaligen und recht klaren Aussage nach nicht das Problem, aber die Angabe einer ID eines nicht existenten Datensatzes.

mysql_affected_rows() hat Martina im Handbuch nicht gefunden, der Tipp ist gegeben.

Fred

[dedlfix]

Tach!

Was hast du probiert und woran bist du gescheitert?
Ist doch offensichtlich. Martina will einfach wissen ob etwas gelöscht wurde.

Es ist offensichtlich, was sie möchte. Das war auch nicht die Frage. Es ist jedoch (mir) nicht ersichtlich, was ihr konkretes Problem beim Anwenden der nachgelesenen Informationen ist.

mysql_affected_rows() hat Martina im Handbuch nicht gefunden, der Tipp ist gegeben.

Dabei steht doch auf der bereits empfohlenen mysql_query()-Handbuch-Seite nicht nur ein Siehe-auch-Verweis sondern explizit im Fließtext, wie man die Anzahl der betroffenen Datensätze bekommt und das auch noch für alle wichtigen Arten von Statements - also nicht nur diese Funktion sondern auch die verwandte mysql_nom_rows(). Ein Anwendungsbeispiel gibt es sogar auch, wenn man den Verweisen zu den Funktionen folgt. Was will man mehr? Oder anders gefragt: Wenn das nicht ausreicht, kann es sich (Unterstellungen beiseite gelassen) eigentlich nur noch um ein Verständnisproblem handeln. Und was das konkret ist, kann ich als Außenstehender nicht erraten, wenn nur ein "funktioniert nicht" gegeben ist, und frage nach.

Ich denke ja, durch den Verweis auf das Handbuch wird einerseits angeregt, doch mehr mit der Dokumentation zu arbeiten. Andererseits findet man in der Doku nebenbei auch noch weitere Informationen abseits des eigentlichen Ziels, an die man sich jedoch hoffentlich erinnert, wenn man ein Problem zu dessen Lösung dieses Nebenbeiwissen beitragen kann.

dedlfix.

[Fred Furunkelstein 2011]

Moin!

Dabei steht doch auf der bereits empfohlenen mysql_query()-Handbuch-Seite nicht nur ein Siehe-auch-Verweis sondern explizit im Fließtext, wie man die Anzahl der betroffenen Datensätze bekommt

Sieh es mal so: Auf die Idee zu kommen, die Anzahl der gelöschten Datensätze zu ermitteln wenn man doch nur wissen will ob man überhaupt einen gelöscht hat, erfordert eine Art der weiblichen Intention wie sie nur bei wenigen Frauen und längst nicht allen Männern erwartet werden kann.

(Hoffentlich muss ich nach diesem üblen, pauschalierenden und politisch unkorrekten Sexismus nicht einen weiteren Nickname benutzen...)

Fred