> -----Original Message----- > From: Andrew Piskorski [mailto:[EMAIL PROTECTED] > Sent: Monday, February 28, 2005 11:17 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] ticket 1147 > > On Mon, Feb 28, 2005 at 09:58:15AM -0800, Tim McDaniel wrote: > > > Given a specific SELECT statement, ADO.NET has the capability to > > automatically build the corresponding INSERT, UPDATE, and DELETE > > statements, so the user can insert/update/delete values/rows in the > > resultset and have those modifications sent back to the > database. But > > > (I wrote the original ADO.NET SQLite wrapper on sourceforge) > > Hm, off topic, but I'm curious: Presumably ADO.NET does not take a > lock out on all those rows and wait around holding it while the human > user goes to lunch. So, when the user changes values and then submits > them, does ADO.NET somehow correctly check that another transaction > has not modified those same rows in the meantime? And what does it do > then, throw a "Someone else has changed your data in the db" > exception?
When ADO.NET generates the update statement, it requires that the select clause include the primary key of the table. If no primary key was selected, then an update clause cannot be generated. Furthermore, when it generates the update statement, the where clause includes all the current values as they existed at the time of the query such that if any field has changed between the time of the query and the time of the update, the update will fail. Programmatically generating insert/update/delete statements is just part of the reasoning behind being able to get schema information for a select clause, however. Robert
