(1) By anonymous on 2020-12-05 16:02:04 [link] [source]
Upon calling sqlite3_close, is the underlying database 'released' i.e. can it be renamed or deleted immediately upon receiving SQLITE_OK?
(2) By Keith Medcalf (kmedcalf) on 2020-12-05 17:02:41 in reply to 1 [link] [source]
The documentation is located here:
If you call sqlite3_close then the answer is yes, if you call sqlite3_close_v2 then the answer is mayhaps yes and mayhaps no.
(3) By anonymous on 2020-12-06 14:00:29 in reply to 2 [link] [source]
I am using C#.
sqlite3_close(dbHandle) returns SQLITE_OK indicating success but I can't subsequently rename/delete the database whose handle is dbHandle (dbHandle is /* OUT: SQLite db handle */ as documented)
int result = sqlite3_open("D:/SQlite32/DB/myDB.db",out dbHandle); int result = sqlite3_close(dbHandle);
After further investigation, I found that dbHandle is NOT (implicitly) released after calling sqlite3_close(dbHandle) from C#. When I release dbHandle, I can rename/delete the database.
Is the behaviour different in C/C++?
If not, shouldn't sqlite3_close(dbHandle) release dbHandle?
(4) By Larry Brasfield (LarryBrasfield) on 2020-12-06 14:57:14 in reply to 3 [source]
In C or C++, the sqlite3_close functions act as the docs (and Keith) say.
Since I do not know what you mean by "release dbHandle", I cannot answer your questions 2.
Here are a few questions to get some missing information.
Are you using the SQLite C library directly from C#?
If yes, how? [a] If no, via what adapter library?
How have you defined dbHandle?
[a. IOW, what are your SQLite API function and data declarations? ]
I find it puzzling that you do not use the System.Data.SQLite library. If you did, you would sidestep a host of problems such as you have posted here.
Given the (sparse) info you provide, it seems that dbHandle must be an instance of something more than a bare pointer to a (C) sqlite3 struct, yet the sqlite3_open() functions cannot possibly know how to properly create anything more C#'ish than a bare pointer. If my supposition is true, that is a big part of your problem.
(5) By anonymous on 2020-12-06 17:24:11 in reply to 4 [link] [source]
Are you using the SQLite C library directly from C#? Yes
If yes, how? [a] If no, via what adapter library? No adapter, via LoadLibrary & GetProcAddress
How have you defined dbHandle? I'm following the documentation
int sqlite3_open( const char *filename, /* Database filename (UTF-8) */ sqlite3 **ppDb /* OUT: SQLite db handle */ );
How have you defined dbHandle? In C#
IntPtr dbHandle; int result = sqlite3_open("d:/sqlite32/db/mydb.db",out dbHandle);
I find it puzzling that you do not use the System.Data.SQLite library. I started off using this but I want to be in control of which SQLite version I use. System.Data.SQLite is still stuck at version 3.32.1 see here. I started by exporting all SQLite3 functions which highlights a difference between v3.34.0's SQLite3.def and what I found.
yet the sqlite3_open() functions cannot possibly know how to properly create anything more C#'ish than a bare pointer. That is why I asked what the behaviour was when using C/C++: if it is different, then it must be my code.
as listed under Using Native Library Pre-Loading available for download?
<bin>\x86\SQLite.Interop.dll (required, x86 native interop assembly)
(6) By Larry Brasfield (LarryBrasfield) on 2020-12-06 21:30:13 in reply to 5 [link] [source]
Before getting to details, I must say that you are a glutton for punishment. I think you would find that far less work would be required to simply build the SQLite.NET version you wish to use than to do all the native code interfacing you have begun to tackle. I also suggest that you would do well to peruse the SQLite.NET code to see how the various challenges you face are met there.
I do not think IntPtr instances are quite the simple objects you imagine. And expecting the call to sqlite3_open to create one, which is in managed memory, is asking for trouble. The type has methods for storing and retrieving the underlying (or contained) raw pointer. I think you should be using them if you insist on holding raw (native) pointers in them. Or you could just use the corresponding int value type big enough to hold data pointers within the SQLite C library as you are building it. Unboxed value types are sized just as you would expect.
SQLite.Interop.dll is just as available for download as all the other pieces that make up a particular, functioning SQLite.NET image/assembly collection.
I dare say that by the time you learn the intricacies of native code interop from CLR-hosted assemblies, the SQLite v3.34.0 library will have been built into another SQLite.NET release.
(7) By anonymous on 2020-12-06 22:29:57 in reply to 6 [link] [source]
the SQLite v3.34.0 library will have been built into another SQLite.NET release.
Precisely - I want to be able to use any version of SQLite I choose (or not use SQLite; there are other alternative serverless RDMS).
Life is too short:
- can't learn everything (and I do not want to learn to learn how to compile SQLite source code with open source compilers). I tried with Visual Studio but nothing fell into place readily - I gave up!. Why? Because that experience will not serve me in any other respect as I have no need to learn C/C++.
- to deny myself the benefits of programming experience accumulated to date
- I think statically binding System.Data.SQLite to a version of SQLite AND not keeping it in line with the current version of SQLite is a mistake. System.Data.SQLite is bound to v3.32.1; that version was released on 25 May 2020. There have been 4 releases since then. I want to avoid the scenario where I am committed to to an earlier release which happens to contain a critical fault (one that has been fixed in a later release and no one has produced bug free software yet).
- I do not want to implement any solution that requires user-managed changes to operating system folders or set up (such as the registry or environment variables), not least because this causes difficulties at client's sites which have corporate policies that deny such changes.
I need to have a look at SQLite.Interop.dll (Visual Studio is capable of auto-generating such files).
And expecting the call to sqlite3_open to create one, which is in managed memory, is asking for trouble.
System.Data.SQLite is doing precisely that and without trouble. Besides, I am not alone in seeking my own solution as regards SQLite3.DLL (as a quick internet search will confirm).