You should understand that Database operated through SQL and TDataSet descendents (TSQLQuery, etc.) are separate layers.
Once you execute SQL statements, like update, insert, select, etc. then it operates directly with the SQLite database file (still temporarily. It is changed permanently when you 'commit' the operations).
When you open SQLQuery with SELECT statements, you'd better think that a copy of the resultant content is created on your local application, which looks like a temporary table. Let's call this dataset, as TSQLQuery is a TDataSet descendent. But still this dataset is invisible.
In order to see the content, you have to use DBControls --- TDBEdit, TDBGrid, etc. Datasource links the previous dataset to these visual controls. If you change any content (or position) in the DataSet, the visual control reflects it via datasource, and once you change content at the visual controls, the content of dataset is modified.
The commands like SQLQuery1.Edit, SQLQuery1.Insert, SQLQuery1.Post, etc. operate on this dataset, not SQLite database itself. Originally Insert, Post, etc. were to operate on local tables like FireFox table, etc.
Any changes to this local dataset is updated to the server file when you call "ApplyUpdates".
So,
once you have Executed 'update ....' SQL (plus transaction.commit), then it's just done.
In order to see the updated content, you have to "OPEN" SQLQuery with 'select.... '. And if you do modify something on the "opened" sqlquery, then ApplyUpdates must be called.
There are some more functions in the TSQLQuery, like using separate SQL statements for insert, update, etc. But I think the you'd better understand what I said first.