Steve, The SQLite library is tested extensively to ensure not just basic functionality but correctness with many thousands of input variations exercising feature combinations. The chance that something as basic as table existence after creation failing, in any version of the library ever released, are **vanishingly** small. The odds are overwhelmingly in favor of your problem being with your code. If you were to use [the CLI shell](https://sqlite.org/2021/sqlite-tools-win32-x86-3360000.zip), with text input of your choosing, to demonstrate the failure that you see, that would be totally on-topic here. If you in fact demonstrated a failure of the SQLite library (which is used by the CLI shell), and reported it here with reproduction steps using that shell, it would be fixed quickly, with thanks for your report and care to author it. What you are seeing is a problem arising from incomplete and ambiguous specification of the database file.<b><sup>1</sup></b> We can see evidence of that in your posts, which has led to the recommendations regarding use of "absolute" and "fully qualified" pathnames to specify the database file. You need to understand what that means and why it is important, which my above link will facilitate with a few minutes of your study. That use of time is far more efficient than you writing here about various GUI apps, button clicks, with improperly rendered pathnames due to markdown misuse, and other arcane details familiar to few here, then hoping somebody can see what you are doing wrong and tell you enough about it after many readers spend their time trying to sort it out for you. Now, I will respond to your post #41 in a way related to this forum topics. > I have used this SQL in my query: "select * from sqlite_masterq" purposely misspelling the table name, and the program runs correctly, giving the "no such table..." message. Good. That means that you know how to recognize when the library report an attempt to reference a nonexistent table with SQL. And you have confirmed correct operation of the library. > This shows to me that the program correctly connects to the specified database name, but when I correct the table name it failed with the external error. This apparently gives meaning to your term, "the external error". It is nothing mysterious -- just an ordinary SQLite library usage error. > I have run the same code in Lazarus, using the same database file name, and it runs fine. That's great news. Now, if you will figure out how to consistently and reliably refer to the same database file<b><sup>2</sup></b> for creation operations, queries, and diagnostic/verification steps, you should be past the problem mentioned in your post #1. Other problems, if they are related to the SQLite library, should appear in a new thread with an apropos title. I encourage you to first replicate such problems with the CLI shell, and post here showing the text inputs, outputs, and what you expected to be different. That effort will help you to separate Delphi/Lazarus/GUI and program logic problems from true SQLite problems. And when you find a true SQLite problem that way, it will be quickly (and efficiently) solved here when presented as I suggest. And there will be no question as to whether the thread is on-topic. ---- 1. As has been already mentioned in this thread: Due to the auto-DB-create feature of sqlite3_open(), successful "connection" **does not imply** that the intended database file has been opened, especially when that intent is weakly expressed with a relative pathname. 2. As has been recommended repeatedly, use absolute (aka "fully qualified") pathnames, per <u>[Microsoft's explanation of Windows pathnames](https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats)</u>, on the Windows OS to avoid ambiguity and ensure replicability as to what file is named.