Will Leshner wrote:
On May 18, 2005, at 8:02 AM, Jay Sprenkle wrote:
When I wrote applications that allowed the user to enter queries
I added the unique key row to their query. I presented them with the
data they requested and either did not show the record id, or made
it read only. This allowed me to correctly identify which record to update
even if they changed every field.
That is what I'm thinking of doing as well. What concerns me is all of the SQL queries that would fail if I blindly add 'rowid' as a column to every query. So it seems I need to be smart about what queries to add it to, and I'm a little worried I'm going to miss cases. In fact, I'm not exactly sure the best way to detect which queries I can legally add 'rowid' to. For example, this query would definitely fail:
SELECT rowid, test1.name FROM test2, test1 WHERE test2.id = test1.id
I'm wondering how you handled this problem.
One way to handle this is to include the rowid from each of the tables being joined.
select
test1.rowid as test1_rowid,
test1.name as test1_name,
test2.rowid as test2_rowid,
from
test2 inner join
test1 on
test2.id = test1.idor whatever sql syntax you prefer.
Myself, I'm not a big fan of high-level abstraction from the sql being performed, so I wouldn't use the originally posted idea of editing a recordset.
