I develop a database wrapper for SQLite and I have an interesting problem that I'm curious how other people solve. Basically, the users of my wrapper have the option of editing database records indirectly through the wrapper, rather than directly, using UPDATE. The database wrapper is a set of classes and one of those classes is a RecordSet. So, when the user asks for a RecordSet, with the intention of editing one or more records, she might do this (where rs is a RecordSet):

rs = db.SQLSelect("SELECT name, age FROM customers")

Now, the user can edit a record in the RecordSet like this:

rs.Edit
rs.Field("name") = "Frank"
rs.Field("age") = 10
rs.Update

What the wrapper does, when it sees the Update, is create SQL and feed it to SQLite:

UPDATE cusomers SET name='Frank', age=10 WHERE name=<old-name-value> AND age=<old-age-value>;

The problem is that the 'name' and 'age' fields are not sufficiently unique to identify the very row the user wanted to update. Instead every row that has matching names and ages are going to be updated.

To solve this problem, I've been telling users to explicitly add 'rowid' as one of their columns when they issue SQL to select records to edit:

rs = db.SQLSelect("SELECT rowid, name, age FROM customers")

This works ok, but I'd really like to get rid of this limitation. I've considered ways of possibly inserting 'rowid' manually to the user's SQL, but the idea of modifying the user's SQL kind of leaves a bad taste in my mouth.

I know that PHP also uses SQLite and I'm wondering if it has the same problem and how it may have solved it.

Thanks for any help.

Reply via email to