> I fail to see why you can't simply include the PRIMARY KEY > (portable) or ROWID (not portable) in your SELECT statement if > you apparently need them later.
I could, but that would involve changing a lot of existing code. If there was a way to get the row id of each column in the result set then it would be simple. I could extract the database,table,column, and row id of the changed column and do the update with a single line of sql. If I include the key of the row in my select(s) how does the program determine which column was the key? I could always make it the first column, but that breaks down for joins. I would have to iterate through the columns in the result set and find what table each came from. Then run a pragma or a select from sqlite_master table to find the index column. That's going to be very slow. It's going to add an extra database operation for every table in the query. This would more than double the time required for each query. If the engine within sqlite recorded the row id as it fetched each column it would be trivial and would prevent me from having to query the database again. If it's not present in the current code I will probably just do it myself. I try not to reinvent the wheel where possible. ;) ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
