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
[EMAIL PROTECTED] ("Uwe C. Schroeder") wrote in message news:<[EMAIL PROTECTED]>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Bastian,
>
> die liste [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
>
> - --
> 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
