Alex Katebi wrote: > Actually I am not interested on rows that have been committed. I am > interested on the rows that have been changed but not commited yet. As I > understand the triggers trigger of of a commit. > The example that you are refering to is for undoing the already commited > rows. I am merely interested in seeing the rows that are in my transaction > queue before the commit. >
SQLite does not have a transaction queue. The data that you have changed is already stored in the database before you do the commit. The commit simply removes the information that would be used to do a rollback. The page I referred you to was an example of using triggers to track changes to tables. This is what you want to do if I understand you correctly. Use triggers to track the rows that are changed by your transaction's insert, update, and delete statements. Then use a select to display the current values (i.e. the value that will be committed) for these rows only. HTH Dennis Cote _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users