Despite my distaste for the [Twenty Questions](https://en.wikipedia.org/wiki/Twenty_Questions) game in troubleshooting situations, I will play for a bit (encouraged by frequent puzzle solver "cuz".) I will point out that the length of this post is increased by the near absence of clues regarding intermediate conditions **known to exist** between a known, reliable starting point and the indisputable, problematic ending point. (More on that later.) > I'm hitting an issue in my application, which basically sums up to the first request executed by a thread failing with 'No such table', while the table definitely exists in the database. It seems the connection refers to an empty database, but I can see content when browsing the database after the application crashed. Why do you believe "a thread", when issuing its "first request", has a DB connection accessing the exact same database as the one which you somehow examined to justify saying "while the table definitely exists"? (This is explored in another few posts here, so if your answer is "No database open call is attempted with more than one absolute path designating the DB file.", then you can translate my question to "Why do you believe that, beyond having intended that it be so?") How can you simultaneously believe (to whatever degree "seems" implies) that "It seems the connection refers to an empty database" and that you "can see content when browsing the database"? Have you taken steps to resolve that conundrum, and if so what were they? Given that the issue is in your application, what diagnostics have you caused to be emitted or logged by the application to validate your ideas as to what states exist when? When you say the "application crashed", are you referring to an address fault and process exit, (the usual definition), or something more mundane such as a program exit upon detection of the same, 'No such table' issue? > I can only reproduce this by running the same test a few times (sometimes the first one is enough) on a rather powerful machine that's usually used for our CI. Does that mean that, sometimes, all DB operations performed by the application succeed? Does it mean that on a different machine they always succeed? Assuming, "yes" and "yes", have you tried reducing the number of independent threads used on the super-duper machine? If so, with what effect? If not, why not? > In order to ensure the database isn't recreated for some reasons I explicitly pass the SQLITE_OPEN_CREATE flag to the first connection, and stick to SQLITE_OPEN_READWRITE for later ones. The failing connection is never the first one, only later ones from a different thread. What ordering criteria determine what you call "first" and "later" here? If it is time, what leads you to believe the ordering you assume is in fact what happens? Have you considered or tried restricting DB operations to a single thread until the DB is known to exist? Have you considered or tried restricting connections to just one, temporarily, (and tolerating possible increased contention which likely will be much less of a problem than you imagine), while you sort out this problem? > Synchronization between threads is handled by the application, and tsan doesn't appear to complain. My web search for "[tsan](https://acronyms.thefreedictionary.com/TSAN)" turns up such unlikely results that I cannot believe any of them are relevant. And I have not yet, in my years of software development, heard of it. Why might "tsan" complain? And what does absence of such complaint tell us? How sure are you that no such complaint occurs? > I'm not really sure what to do/test from here, so any help would be highly appreciated! There are several things that you can and should do, all falling under the guise of traditional, proven debugging techniques. One is to validate your own notions of what is happening and what is not. Emitting or logging diagnostics is in that category. So is running your application under a debugger, breaking where the error is detected, then examining variables and (for on-disk DB issues) using an independent means of examining relevant file contents. (The SQLite CLI shell is good for this.) At present, you seem to have little idea where things are going wrong, and so the range of possibilities is vast. With improved visibility as to what is or is not true in more limited portions of your application's operation, you will be able to reduce the extent of your focus and deal with a smaller problem. This reduction can usually be applied recursively, until the problem is so small that you can thoroughly research your related assumptions and discover which are incorrect, or (in rare cases) be sure that some code other than yours is not behaving as its documentation says it should. Good luck, and be sure to come back with more clues if you have diligently narrowed the problem. And by "clues", I mean observable, falsifiable facts rather than suppositions and assumptions as to what you believe or wish is happening.