Moin!
und das mit der ID-Kennung habe ich ehrlich gesagt auch nicht ganz verstanden ...
Ein Datensatz muß eine eindeutige ID haben, mit der er für interne Zwecke identifiziert werden kann. Intern im Sinne von "sieht der Benutzer nicht (unbedingt)".
Wenn du Projekte und Angebote in zwei Tabellen hast, dann muß jedes Angebot und jedes Projekt eine eindeutige ID haben. Ob du diese ID auch für den Benutzer verwendest (damit er die Projektnummer oder die Angebotsnummer direkt eingeben kann), bleibt dir überlassen - es sieht nur manchmal etwas doof aus, wenn ein Kunde "Projekt 000000001/Auftrag 0000000001" erhält, man aber irgendwie das Gefühl erzeugen will, man sei schon länger im Geschäft. :)
Deshalb wirst du vermutlich toll aussehende Projekt-/Aufgabennummern haben wollen, welche aber nicht zwingend als interne ID geeignet sind, weil man an der öffentlichen Projekt-ID vielleicht doch mal was (rein optisch) ändern möchte.
Deshalb brauchst du eine interne ID. Und auf die beziehst du dich beim Bearbeiten. Wenn du eine (Auswahl-/Suchergebnis-)Liste von einigen Datensätzen hast, übergibst du im Link zur Bearbeitungsseite die intere ID, nicht die öffentliche. Und wenn der Benutzer eine öffentliche Projekt/Angebotsnummer eingibt, suchst du in der Datenbank, welche interne ID dazugehört, und läßt alle weiteren Aktionen immer auf der gefundenen (hoffentlich findest du nur eine einzige) internen ID basieren. Beispielsweise mußt du beim Ändern von Datensätzen ja irgendwie speichern, welchen Datensatz du ins vorausgefüllte Formular geschrieben hast. Und dazu eignet sich die nicht bearbeitbare, weil unveränderliche intere ID bestens:
<input type="hidden" name="interneID" value="23">
So kannst du die abgeschickten, möglicherweise veränderten Daten dem richtigen Datensatz zuordnen:
UPDATE set x=y.... WHERE interne_ID = 23;
- Sven Rautenberg
Signatur oder nicht Signatur - das ist hier die Frage!