-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bastian,
warum die Tabelle nicht so aufbauen:
create table jadajada (
internal_number serial primary key,
nr int4,
testdaten varchar(254)
);
die "internal_number" wird dann automatisch von postgres vergeben. Dann kannst
du deine nummern umschieben wie du willst, die interne nummer wird sich nie
�ndern. Die interne nummer benutzt du um den delete, update etc. zu
kontrollieren ala:
delete from jadajada where internal_number=12345;
Die Nr. degradiert zu einem normalen datum was beliebig ge�ndert werden kann.
Du gibst die interne nummer in deiner Applikation nat�rlich nicht aus. Die
w�re f�r den Benutzer eher verwirrend.
Uwe
On Thursday 06 May 2004 02:40 am, Bastian wrote:
> 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])
- --
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)
iD8DBQFAmtkBjqGXBvRToM4RAsiTAKC2AwKxVjhhu10pRKREE96bg8jpNQCdFqMR
9DI4/PiQFH01Aq7JVGQHZAM=
=E3qO
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
