If you have a table t1, you could create a table that stored the changes to t1, i.e. t1_change.
You could then create a trigger on t1 that wrote data to t1_change. Exactly what you would need to store would depend on the structure of t1, but it would presumably be something that uniquely identified the row. The primary key would be preferrable, though, you could use ROWID as well. The precise needs of the extract process will matter here as well. How are DELETE's handled? Do you need to extract the complete "before" image of the deleted row? What about for UPDATE's? Do you need to know the old data or just the new data? How are multiple changes to the same row handled? If I INSERT, UPDATE, and then DELETE a row between extracts, do you need to note all those changes or just the final status?
The extract process would read from t1_change, potentially do a lookup for the new data in t1, extract the data, and delete the row from t1_change.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC