Erfolg der Löschung einiger mysql-Datensätze

Dieses Thema im Forum "Web-Programmierung" wurde erstellt von comrat, 29.05.2005.

  1. comrat

    comrat Thread Starter MacUser Mitglied

    Beiträge:
    112
    Zustimmungen:
    0
    MacUser seit:
    27.12.2004
    Hallo,

    wie überprüft man professionell, ob die Löschung einiger Datensätze erfolgreich war? Sicherlich finde ich dazu eine eigene Lösung, aber, um unnötige Versuche zu vermeiden, hätte ich gerne vorher gewußt, welchen Weg man dazu grundsätzlich einschlagen sollte.

    Fragt Ihr erst per select wieviele Datensätze betroffen sind, löscht diese und prüft dann mit mysql_affected_rows(), ob dieselbe Anzahl gelöscht wurde? Sicher fühle ich mich mit dieser Variante aber nur, wenn ich die Datenbanken vorher sperren konnte (alte Clipper/DBase-Erfahrung). Welche Stichwörter muß ich lesen um den lock und unlock durchzuführen?

    Danke für jeden konstruktiven Hinweis.
     
  2. Katana

    Katana MacUser Mitglied

    Beiträge:
    989
    Zustimmungen:
    0
    MacUser seit:
    30.08.2004
    du kannst es anhand des query-results und mit hilfe der beiden funktionen weiter unten ermitteln:

    $query = "...";

    $result = mysql_query($query);
    if (!$result) { // FEHLER!

    // hier entsprechend handeln
    }

    [DLMURL]http://de3.php.net/manual/en/function.mysql-errno.php[/DLMURL]
    liefert den numerischen fehler-code der letzten mysql-operation

    [DLMURL]http://de3.php.net/manual/en/function.mysql-error.php[/DLMURL]
    liefert eine beschreibung des fehlers der letzten mysql-operation
     
  3. comrat

    comrat Thread Starter MacUser Mitglied

    Beiträge:
    112
    Zustimmungen:
    0
    MacUser seit:
    27.12.2004
    result von mysql_query unzureichende Erfolgsprüfung?

    Danke Katana,

    ausschließlich das result von mysql_query() zu überprüfen scheint mir unzureichend. result kann mir nur mitteilen, daß ein syntaktischer oder ein semantischer Fehler vorlag oder die Zugriffsrechte unzureichend waren.

    Die erwartete Zahl zu löschender Datensätze scheint unberücksichtigt zu bleiben in Deinem Beispiel; die unerwartete Zahl gelöschter ebenfalls.

    Habe ich etwas übersehen?
     
  4. Katana

    Katana MacUser Mitglied

    Beiträge:
    989
    Zustimmungen:
    0
    MacUser seit:
    30.08.2004
    nein, du hast schon recht ... auf die anzahl der gelöschten datensätze gehe ich in dem beispiel nicht ein ... du müsstest dann einfach noch mysql_affected_rows mit auswerten?
     
  5. comrat

    comrat Thread Starter MacUser Mitglied

    Beiträge:
    112
    Zustimmungen:
    0
    MacUser seit:
    27.12.2004
    Sperrung auch bei delete nicht erforderlich?

    Zitat-Anfang
    [DLMURL="http://dev.mysql.com/doc/mysql/de/lock-tables.html"]Normalerweise müssen Sie Tabellen nicht sperren, weil alle einzelnen UPDATE-Statements atomisch sind. Kein anderer Thread kann mit einem aktuell ausgeführten SQL-Statement in die Quere kommen.[/DLMURL]
    Zitat-Ende

    Nur, wie sieht es mit einem Delete aus? Eine Sperrung brauche ich nur, wenn ich zwischen einem select und einem delete keine Veränderungen zulassen möchte, oder wenn ich die Ausführungszeit verringern möchte.

    Einen deadlock, nicht-blockierungsfreies Sperren, scheint nicht stattfinden zu können, da, wenn ich das richtig verstanden habe, die Tabellen in einer festen, sortierten, Folge gesperrt werden.
     
    Zuletzt von einem Moderator bearbeitet: 10.11.2015
  6. Katana

    Katana MacUser Mitglied

    Beiträge:
    989
    Zustimmungen:
    0
    MacUser seit:
    30.08.2004
    ja? und? verstehe dein problem wohl nicht ganz ...

    befürchtest du, dass du auf daten zugreifen (wollen) könntest, die anderswo gerade gelöscht wurden/werden? falls ja, reicht eine prüfung in den routinen, die auf die daten zugreifen wollen ...

    oder ist etwas anderes gemeint?
     
  7. comrat

    comrat Thread Starter MacUser Mitglied

    Beiträge:
    112
    Zustimmungen:
    0
    MacUser seit:
    27.12.2004
    Ich dürste ;-) nach einem Wink, der mir sagt, wie Ihr Datensätze löscht. Sperrt Ihr die betroffenen Tabellen erst, oder besteht kein Risiko, daß während der Löschung Änderungen Anderer laufen, die ein konkurrierend produziertes, aber fehlerhaftes Ergebnis in der Datenbank zurücklassen?

    Ist zum Beispiel eine Tabelle dafür zuständig, Bestände dreierlei Art synchron zu halten und werden die Bezeichner der Art durch einen Generationswechsel verschoben, dann darf während dieser Verschiebung keine Löschung stattfinden.

    tab_artikel

    tab_generation.art="alt"
    tab_generation.art="aktuell"
    tab_generation.art="neu"

    Zu jedem Artikel gibt es in einer angehängten Tabelle drei Datensätze unterschiedlicher Generation.

    Erzeugt eine Task gerade einen Datensatz .neu, verschiebt sie die Datensätze .alt und .aktuell. Löscht meine Task aber fast zeitgleich alle .alt mit einer passenden Filterung, dann greift die Verschiebung plötzlich ins Leere. Ups!

    Wie handhabt Ihr so etwas? Einige Stichwörter in chronologisch sinnvoller Reihenfolge sollten mir reichen um auf den richtigen Weg zu kommen. Danke.
     
    Zuletzt bearbeitet: 30.05.2005
  8. comrat

    comrat Thread Starter MacUser Mitglied

    Beiträge:
    112
    Zustimmungen:
    0
    MacUser seit:
    27.12.2004
    Das wird ja immer besser *grübel*

    Zitat-Anfang
    Zitat-Ende

    So wird die Frage nach der Dringlichkeit der Tabellensperrung immer drängender. ;-)
     
  9. maceis

    maceis MacUser Mitglied

    Beiträge:
    16.645
    Zustimmungen:
    596
    MacUser seit:
    24.09.2003
    Solche Fragen würde ich in de.comp.datenbanken.mysql stellen.
    HTH
     
  10. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.045
    Zustimmungen:
    1.318
    MacUser seit:
    13.09.2004
    Datenbanken nutzt man, um ihnen die Aufgabe der strukturierten Datenhaltung zu überlassen, gerade auch mit konkurrierendem Zugriff. Jede Abfrage zu hinterfragen, hieße ja das DBMS nicht funktionieren. Sofern keine Fehlnutzung seitens des Programmierers vorliegt, kann man schon davon ausgehen, daß DBMS ihrem Job nachkommen!