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

 

USEFUL?
We benefit hugely from resources on the web so we decided we should try and give back some of our knowledge and resources to the community by opening up many of our company’s internal notes and libraries through mini sites like this. We hope you find the site helpful.
Please feel free to comment if you can add help to this page or point out issues and solutions you have found, but please note that we do not provide support on this site. If you need help with a problem please use one of the many online forums.