> -----Original Message----- > From: Jay [mailto:[EMAIL PROTECTED] > Sent: Monday, February 28, 2005 11:08 AM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] ticket 1147 > > > > On Mon, 2005-02-28 at 08:48 -0700, Robert Simpson wrote: > > > > 5. What we do with the schema information or how well we > > > compute it > > > > is irrelevant. > > > > > > > > > > No. It is exceedingly relevant if you want any cooperation > > > from me in addressing the issue. > > > > > > There seem to be a lot of people who are emphatic about > > > knowing which column in which table a value in the result set > > > originated from. This makes no sense to me. Why do they > > > care? What do these people do with result set values that > > > originate from expressions or which are constants? What > > > about the result set of compound selects or of natural joins > > > where the origin column is ambiguous? If knowing the > > > original column is so important, what do people do with those > > > cases? Disallow them? What do other database engines > > > (PostgreSQL, Oracle, MySQL) do in the way of revealing the > > > originating column for result set values? Do they have some > > > mysterious API that I have never seen? > > > > > > And why do people care? Can nobody give me a use case where > > > it is important to know what the originating column for a > > > result set value is? > > > > > > > One example, ADO.NET (Robert S., correct me if I'm wrong here): > > > > 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 > > in order to facilitate this, it must have a direct mapping between > > resultset columns and the originating columns in the database. > > > > Tim McDaniel > > (I wrote the original ADO.NET SQLite wrapper on sourceforge) > > Interesting! > How do they handle calculated columns and constraints and such? > Does it just fail?
Any computed column lacking a base table and base column mapping is marked "read only" and is ignored by ADO for the sake of Generating INSERT/UPDATE statements. If there is no column in the select clause that backs to a table, then the statements will fail to generate. If there is no column that has a primary key, then the update statement and delete statements cannot be automatically generated either. Robert
