We've found this can happen if executing an update after a read on a sqlite database file.  Tried all sorts of fixes, closing the connection in between, etc, etc, but nothing other than a long sleep delay would fix it.  From reading up it seems sqlite works in the background after returning from calls such as ->Read and from what we've seen there seems to be a bug in that ->Read isn't actually done when it returns and it then locks up into wait for timeout state when updating the datab ase straight after on the same thread (which causes the database to be locked while the update is carried out).

Anyway, the fix we found was to do this after the Read is complete:

	Reader1->Close();

	//Bugfix to workaround sqlite "database is locked" issue when updating after a read
	while (!Reader1->IsClosed)
		System::Threading::Thread::Sleep(1);		//mS