> Yes, but there are some things I don't like about it -- see my earlier > reply in this thread (to Simon's first message).
Gotta say I could not follow what you said in the earlier reply. It would be nice if you could explain in some finer detail. That said, I would personally favor using "standard" SQLite3 if possible. > Alternatively, I was thinking about this idea: If it is not possible to > persist savepoints, then I could simply discard the uncommitted changes > when the connection is closed, and redo them on the next startup of the > application. In my particular situation, this is possible (the > information needed to redo the changes is available) and may be > acceptable performance-wise. Makes sense to me. I just had the following idea that I hope can satisfy your use case a little more smoothly: Add some kind of a record state column that you can use to track which "saveset" you want for each record in the database. (You would probably use a special "saveset" number to mean that you want to persist the record unless you decide to explicitly remove it someday.) Then it should be really easy for you to include or exclude certain records when selecting based on your "saveset" number. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
