nicht angemeldet
Moin!
Danke für deine Antwort. Das Problem ist, dass ich nach dem Eintragen den _gesamten_ Datensatz auslesen will, also nicht nur der Wert des auto_increment-Feldes. Ich denke das geht nur, indem man nach dem Eintragen wieder eine SELECT-Abfrage platziert. Das Problem ist: wie bekomme ich den zuletzt eingetragenen Eintrag einer Tabelle, deren Struktur völlig egal sein muss?
Ich sehe irgendwie nicht so ganz dein Problem.
Entweder hat deine Funktion definiert bekommen, wie die Tabellenstruktur der verwendeten Datenbank aussieht. Dann weiß sie deshalb auch, welche Spalte die ID-Spalte ist, und kann dieses Wissen für ein nachfolgendes SELECT nutzen.
Oder deine Funktion weiß nichts über die Tabellenstruktur. Dann muß sie sich drauf verlassen, dass der Funktionsaufrufende diese Kenntnis hat, und kann dann von diesem zusätzlich anfordern, dass er die ID-Spalte als weiteren Parameter übergibt.
Schließlich mußt du dich ja sowieso drauf verlassen, dass auch die Felder für die übergebenen Werte sowie die dann auszulesenden Felder in der Tabelle schon existieren. Ansonsten kriegst du beim Abschicken des Querys einen Fehler um die Ohren und hast den Aufrufer darüber zu informieren.
Wenn man zum Beispiel wüsste, dass in der Tabelle das auto_increment-Feld "ID" existiert wäre das kein Problem (-> "SELECT FROM $table WHERE ID = mysql_insert_id();"), das auto_increment-Feld - falls überhaupt eines existiert - könnte aber auch einen anderen Namen tragen.
Mir sind Anwendungsfälls suspekt, bei denen angeblich die totale Flexibilität herrschen soll. Eine Applikation benötigt ein festgelegtes Datenmodell, ansonsten kann man damit nicht arbeiten. Und selbst wenn es um eine Applikation geht, die ein vom Anwender definierbares Datenmodell haben soll, wird man in solchen Fällen programmierseitig dann ein festes Datenmodell für das flexible Datenmodell bauen.
Ausnahmefälle hierfür sind in meinen Augen wirklich nur so Anwendungen wie Datenbank-Admin-Programme (phpMyAdmin), deren Aufgabe einfach von einer anderen Qualität ist, und die aber eigentlich die gesamte Verantwortung für das erfolgreiche Gelingen der vom Anwender initiierten Aktionen auf den Anwender abwälzen, und nur den "zufällig" erfolgreichen Query als Tabelle zurückliefern, andernfalls aber auch nur die Fehlermeldung der Datenbank, und nichts sonst.
Solch ein Verhalten ist in anwenderfreundlichen Applikationen für den Nicht-SQL-Könner aber nur bis zu einem gewissen Level möglich - in irgendeiner Schicht der Applikation muß die Fehlermeldung der DB irgendwie in eine vernünftige Reaktion an den Anwender transformiert werden.
- Sven Rautenberg
"Love your nation - respect the others."