Re: Verhindern, dass im Mehrbenutzerbetrieb mit veralteten Daten gearbteitet wird - Mailing list pgsql-general

Hallo Uwe,

zunächst einmal danke für die schnelle Antwort und den Tipp meine
Anfrage auf Englisch zu stellen. Ich werde das beim nächsten Mal
berücksichtigen.

Zum Problem: Wenn ich die Datensätze eindeutig identifiziere, kann ich
das Problem nicht beheben.
Beispiel:
Ausgangstabelle:

Nr      daten
1       testdaten1
2       testdaten2
3       testdaten3

Wenn nun Benutzer 1 den Datensatz mit der Nr.2 - also "testdaten2" -
löscht, so sollen sich die Nummern verschieben und die Tabelle sieht
folgendermaßen aus.

Nr      daten
1       testdaten1
2       testdaten3

Der zweite Benutzer würde dann also bei einem Zugriff auf Nr.2 nicht
wie gewünscht "testdaten2" löschen, sondern "testdaten3".
Wenn sich die Nummern nicht verschieben würden, also die Tabelle so
aussieht:

Nr      daten
1       testdaten1
3       testdaten3
dann würde der DELETE bzgl. Nr.2 ins Leere gehen.


Bastian


uwe@oss4u.com ("Uwe C. Schroeder") wrote in message news:<200405051100.06834.uwe@oss4u.com>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Bastian,
>
> die liste pgsql-general@postgresql.org is 99% in englisch. Deine Anfrage ha
> t
> wesentlich mehr Aussicht auf Erfolg wenn die sie in englisch stellst.
>
> Zum Problem: kannst du die Datens tze nicht eindeutig identifizieren ? Um
>
> erfolgreich einen Lock zu setzen muss die Tabelle einen primary key haben,
>
> der dann eindeutig ist. Damit h ttest du zumindest nicht das Problem da
>   ein
> Datensatz gel scht wird der "zwar die gew nschte Nr hat, aber nicht meh
> r der
> Datensatz ist". Du kannst explizite rowlocks setzen, aber wie gesagt es ist
>
> einfacher die rows eindeutig zu identifizieren, dann kann der Benutzer mit
>
> der veralteten Ansicht zwar noch l schen, der delete geht dann aber ins
>
> leere. Nur ein update auf den veralteten datensatz wird einen fehler
> erzeugen, den deine Applikation dann mit entsprechender fehlermeldung
> abfangen muss.
>
> UC
>
> On Tuesday 04 May 2004 01:50 am, Bastian wrote:
> > Hi,
> >
> > ich benutze PHP und PostgreSQL.
> > Folgendes Problem: Eine Seite zeigt die Daten, die in einer Tabelle
> > der DB abgespeichert sind. Der Benutzer w hlt dann einen Datensatz
> > aus, den er gerne bearbeiten oder l schen m chte. Auf der n chsten
> > Seite wird die Aktion dann ausgef hrt.
> > Es ist m glich LOCKS zu setzen, um zu verhindern, dass sich 2 DELETES
> > bzw. UPDATES in die Quere kommen, bzw. werden implizit gesetzt. Aber
> > wenn ein Benutzer sich auf Seite 1 also auf der Tabellenabfrageseite
> > befindet, und ein anderer Benutzer w hrend dessen die Daten in der
> > Tabelle ver ndert, so arbeitet Benutzer 1 mit den alten Daten und
> > l scht dann z.B. einen Datensatz der zwar die gew nschte Nr hat, aber
> > nicht mehr der Datensatz ist, den er eigentlich l schen wollte.
> > Ist es vielleicht m glich per Abfrage zu pr fen, ob gerade ein LOCK
> > gesetzt ist?
> >
> > Bastian
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
> - --
>     UC
>
> - --
> Open Source Solutions 4U, LLC    2570 Fleetwood Drive
> Phone:  +1 650 872 2425        San Bruno, CA 94066
> Cell:   +1 650 302 2405        United States
> Fax:    +1 650 872 2417
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
>
> iD8DBQFAmSumjqGXBvRToM4RAoJTAJ42xi25CzUpgnbjUrEJutTCF9+OxQCbBzSh
> BxpIwG8QEsIPxQUp39U5Fa8=
> =7BB1
> -----END PGP SIGNATURE-----
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html