Transaction (T-SQL) & PHP?

[Lilith]

Hallo!
Wie immer zu Beginn die Informationen über das System/ PHP:

PHP-Version: PHP 4.3.0
Apache 1.3.2.6 --> auf Suse 8
Datenbank: MS SQL 7.0 --> auf W2K Server

Ersteinmal erkläre ich euch wohl am besten, was ich realisieren möchte:
Auf Knopfdruck soll ein Datensatz gesperrt werden,
soll der User Daten einträgen/ ändern können,
anschließen soll auf 'Speichern' der Datensatz gespeichert werden.

Das habe ich realisiert:
User sieht Daten an (readonly), auf bearbeiten kann er die FElder bearbeiten, die er bearbeiten darf.
Auf 'abbrechen' werden Änderungen verworfen und der der User geht zurück in die readonly-Ansicht.
Bei 'speicher' ist bis jetzt nichts.

Idee:
T-SQL Transaktion

Habe leider kaum Ahnung davon und bis jetzt nicht viel Information dazu gefunden. Ich weiß, dass es funktionieren würde, würde ich das auf "einen Abwasch" machen, d.h.

BEGIN TRANSACTION @TranName
DECLARE @TranName VARCHAR(20)

SELECT @TranName = 'MyTransaction'
GO
USE pubs
GO
UPDATE mitarbeiter
SET name = 'bob' WHERE id = '2'
GO
COMMIT TRANSACTION MyTransaction
GO

FRAGE:
Kann ich das auch aufsplitten? Denn dann würde ich ein 'unvollständes' SQL - Statement absetzten????

Ich könnte Informationen gebrauchen, vielleicht auch links oder auch quelltext Auszüge. Oder sagt mir, wie man das besser lösen kann.
Ich wäre für jede Hilfe dankbar!!!


Viele liebe Grüße,
Lilith

[Abraxax]

ich würde das eher dem sql-forum zuordnen. da wirst du wahrscheinlich besser geholfen.

*VERSCHIEB*

[Lilith]

no prob

War mir auch nicht sooo sicher, wohin nu' damit.
Steht jetzt im anderen Forum...

Grüße, Lilith

[Abraxax]

ich habe diesen thread verschoben.
deinen anderen (crossposting) habe ich geclosed

[TobiaZ]

Ich versteh nicht so ganz, was du mit Transaction erreichen willst.

[Lilith]

Transaction

Ich soll den Datensatz sperren, damit verhindert wird, dass während der Bearbeitungszeit kein anderer User die Daten ändert.
Also soll immer nur ein User in den Bearbeiten-Modus wechseln können.
Mit meinem 'gefährlichen Halbwissen' bin ich auf Transaction gekommen.

Wenn du eine bessere Idee, dann gern her damit! bIn für alles offen...

Lilith

[TobiaZ]

Okay, das hatte ich nicht ganz gecheckt. Da macht dass dann schon Sinn, denke ich. Aber mehr kann ich dir leider nicht dazu sagen

[mrhappiness]

und was hindert den anderen user etwas zu warten und den datensatz dann zu ändern?

du brauchst die sperre doch nur solange wie dein update-befehl läuft oder?
da hab ich das für dich:

Sperren sind beim SQL Server implizit; der Programmierer braucht sich darum keine Gedanken zu machen. Der Prozeß, einen Datensatz zu sperren, ist außergewöhnlich schnell; es handelt sich hier um Mikrosekunden, bis die Information in einer speicherresidenten Tabelle gespeichert ist. Es gibt mehrere Grade der Sperren; der SQL Server nimmt jeweils den niedrigsten Grad, der noch ausreicht, die Operation zu unterstützen.

[Lilith]

Das kann

ich leider nicht allein entscheiden.
Wunsch des Auftraggebers ist es, den Datensatz solang zu sperren, bis der ihn wieder freigibt (durch update oder abbrechen).

Folgender Hintergedanke:
User A holt sich daten und beginnt veränderung
User B holt sich daten und beginnt veränderung
User A führt update aus
USer B würde bei einem Udate vielleicht Daten überschreiben, die er nicht überschreiben möchte.

[TobiaZ]

@happy:
Was machst du, wenn der eine gerade den text schreibt, dabei der nächste auch bearbeiten aufruft, der erste seinen text speichert. danach "überschreibt" der Zweite ja den Text des ersten.

[mrhappiness]

also, halbe statements kannst du nich absetzen. dann würd ich vorschlagen du machst es so:

die tabelle die du editieren willst, hat doch sicherlich einen primary key oder?

mach ne neue tabelle lockedrecords die den primary key der zu ändernenden tabelle enthält.

wenn user b jetzt den eintrag ändern will, schaust du in lockedrecords nach, findest den primary key dadrin und gibst an user b ne meldung aus, dass der eintrag gerade bearbeitet wird

@Tobi
dachte es soll verhidnert werden, dass der server meckert, wenn zwei gleichzeitig einen datensatz ändern wollen.

dass user b nachträglich das von user a überschreiben kann wird sich nicht vermeiden lassen