Griggs, Donald wrote: > When you wrote: "... but I didn't want to keep track of an additional > ID in the application but instead let the database do the work." > > I don't think I understand what logic the database is supposed to use to > determine this. If you were talking to a database that was as smart as > a human, how would you instruct it to choose the proper record without > an eventId?
Well, I don't need an eventId in the application. All I need is the information about the startevent and the corresponding stopevent. SQLite *can* collect the necessary information (see the select in my initial posting) for *my usecase*. The misbehaviour that I reported is confirmed as a bug and corrected by Dan. So the database hasn't to be as smart as a human, it only has to be as smart as SQLite, and I try to instruct it with my limited SQL knowledge. ;-) I, personally, try to reduce application logic to simple insert, select and delete statements. Anything else related to the data stored in the database and the relations between the tables should be handled by the database itself (with the help of the application programmer of course by means of triggers, database procedures and functions). Normally, if handled internally, the database is much faster to do the adequate things than an application through an interface can do. And as a result of that this is the single point on my wish list for SQLite: Stored procedures and functions with support for variables. Ingo _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
