SQLite Forum

Timeline
Login

50 forum posts by user LarryBrasfield occurring on or before 2021-01-01 01:02:47.

More ↑
2021-01-01
01:02 Edit reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: e207f28f6f user: LarryBrasfield)

The "bug tracker" is not visible outside of the SQLite dev group. Bugs are reported in this forum. Although Richard Hipp has already noticed this thread, it may still be worthwhile for you to edit the thread title to something like: "Bug: ceil and floor function addresses cannot be taken in MSVC (diagnosed)" (I suggest you do it because you, as the thread originator, are privileged to do so.)

I doubt the SQLite developers will regard this as a non-issue. The Microsoft C compiler has been extensively catered to already. This is just more of the same.

01:00 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: 5ad7d60a40 user: LarryBrasfield)

The "bug tracker" is not visible outside of the SQLite dev group. Bugs are reported in this forum. Although Richard Hipp has already noticed this thread, it may still be worthwhile for you to edit the thread title to something like: "Bug: ceil and floor function addresses cannot be taken in MSVC (diagnosed)" (I suggest you do it because you, as the thread originator, are privileged to do so.)

00:26 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: fc91bc347b user: LarryBrasfield)

This is probably inherently correlated with the intrinsic aspect of ceil and floor. The corresponding FPU (floating point unit) instructions are going to be faster and/or more precise, the former by avoiding a function call and the latter by often using the FPU's higher precision intermediate results.

00:17 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: 8f3cda171a user: LarryBrasfield)

You've got your finger on it. It suffices to get #pragma function(ceil, floor) into the sqlite3.c compilation before the address of either "function" is taken. Then, whether SQLITE_DISABLE_INTRINSIC is #define'd or not, those 3 errors vanish.

2020-12-31
20:34 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: 14c7a988ef user: LarryBrasfield)

Interesting, maybe. Perhaps stranger than either of us yet understands.

I was using compiler version 19.27.29111 for x64, almost 4 months "old".

My omission is closer to neglecting to say when in a given model/year's production run the vehicle was made. This is not to say that the revision level is unimportant. It may yet be shown to be critical.

Updating to Visual Studio 16.8.3, (CL v19.28.29335 for the 64-bit toolset), followed by a restart, does not clear the OP's reported errors with my build options.

With my hacky work-around, (to get an executable), I get this from the pragma_compile_options virtual table: ┌─────────────────────────────┐ │ compile_options │ ├─────────────────────────────┤ │ COMPILER=msvc-1928 │ │ DEFAULT_FOREIGN_KEYS │ │ DEFAULT_SYNCHRONOUS=3 │ │ DEFAULT_WORKER_THREADS=3 │ │ ENABLE_BYTECODE_VTAB │ │ ENABLE_COLUMN_METADATA │ │ ENABLE_DBSTAT_VTAB │ │ ENABLE_FTS4 │ │ ENABLE_FTS5 │ │ ENABLE_GEOPOLY │ │ ENABLE_JSON1 │ │ ENABLE_MATH_FUNCTIONS │ │ ENABLE_PREUPDATE_HOOK │ │ ENABLE_RTREE │ │ ENABLE_SESSION │ │ ENABLE_STMTVTAB │ │ ENABLE_UNKNOWN_SQL_FUNCTION │ │ LIKE_DOESNT_MATCH_BLOBS │ │ MAX_TRIGGER_DEPTH=100 │ │ OMIT_DEPRECATED │ │ OMIT_SHARED_CACHE │ │ TEMP_STORE=2 │ │ THREADSAFE=0 │ │ UNTESTABLE │ │ USE_ALLOCA │ │ USE_URI │ └─────────────────────────────┘ Will you please provide your compile options to aid my further investigation?

18:36 Edit reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: b22425904a user: LarryBrasfield)

I post the following as clues resulting from my investigation, not as a solution.

If these two functions definitions follow #include <math.h>: static double vsCeil( double a ) { return ceil(a); } static double vsFloor( double a ) { return floor(a); } and the VS20{17,19} choking lines: MFUNCTION(ceil, 1, ceil, ceilingFunc ), MFUNCTION(ceiling, 1, ceil, ceilingFunc ), MFUNCTION(floor, 1, floor, ceilingFunc ), are replaced with: MFUNCTION(ceil, 1, vsCeil, ceilingFunc ), MFUNCTION(ceiling, 1, vsCeil, ceilingFunc ), MFUNCTION(floor, 1, vsFloor, ceilingFunc ), , then sqlite3.c compiles under VS2019 without producing the errors reported by the OP. Why this is remains a mystery to me. The next line of code: MFUNCTION(trunc, 1, trunc, ceilingFunc ), compiles fine, and as far as I can see (while looking at preprocessor output with the same preprocessing options and definitions as for the failing compile), the ceil, floor and trunc functions are declared identically. (ie: __declspec(dllimport) double __cdecl ceil( double _X); __declspec(dllimport) double __cdecl floor( double _X); __declspec(dllimport) double __cdecl trunc( double _X); ). Yet replacing 'ceil' or 'floor' in the 3 failing lines with 'trunc' also eliminates the VS2019 complaints (while being mathematically incorrect.)

It's enough to make me wonder if those functions are resolving to an FPU intrinsic or some such goofiness, such that their names do not resolve to the address of an executable function. I'll have to look into this further.

18:34 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: 4d255766ad user: LarryBrasfield)

I post the following as clues resulting from my investigation, not as a solution.

If these two functions are defined after #include <math.h>: static double vsCeil( double a ) { return ceil(a); } static double vsFloor( double a ) { return floor(a); } and the VS20{17,19} choking lines: MFUNCTION(ceil, 1, ceil, ceilingFunc ), MFUNCTION(ceiling, 1, ceil, ceilingFunc ), MFUNCTION(floor, 1, floor, ceilingFunc ), are replace with: MFUNCTION(ceil, 1, vsCeil, ceilingFunc ), MFUNCTION(ceiling, 1, vsCeil, ceilingFunc ), MFUNCTION(floor, 1, vsFloor, ceilingFunc ), , then sqlite3.c compiles under VS2019 without producing the errors reported by the OP. Why this is remains a mystery to me. The next line of code: MFUNCTION(trunc, 1, trunc, ceilingFunc ), compiles fine, and as far as I can see (while looking at preprocessor output with the same preprocessing options and definitions as for the failing compile), the ceil, floor and trunc functions are declared identically. (ie: __declspec(dllimport) double __cdecl ceil( double _X); __declspec(dllimport) double __cdecl floor( double _X); __declspec(dllimport) double __cdecl trunc( double _X); . Yet replacing 'ceil' or 'floor' in the 3 failing lines with 'trunc' also eliminates the VS2019 complaints (while being mathematically incorrect.)

It's enough to make me wonder if those functions are resolving to an FPU intrinsic or some such goofiness, such that their names do not resolve to the address of an executable function. I'll have to look into this further.

16:59 Reply: Bug: MSVC uses intrinsic versions of ceil and floor for floating-point modes precise and fast (diagnosed) (artifact: 2cfc90d22a user: LarryBrasfield)

FWIW: Visual Studio 2019 compiler produces the same errors at the same place. I have yet to discern why line 120001 and subsequent uses of MFUNCTION macro do not produce the same error while being identical with respect to signatures and data declarations. Still investigating.

2020-12-28
23:47 Reply: Missing comma in ctime.c (artifact: d2de04cf31 user: LarryBrasfield)

The sources in src/* are not auto-generated. You must be looking at some code which is auto-extracted and amalgamated from those sources where comments are auto-placed warning against edits.

2020-12-23
23:13 Reply: Column Type (artifact: aca82cfaaf user: LarryBrasfield)

There is a SQL function called typeof(). Writing a query to effect the decision heuristic you prefer should be simple. However, I think your desire to do so signifies the start of a fight with the SQLite type scheme that would be better avoided by putting the type(s) you intend for each column into the table(s) as original data.

05:41 Reply: Is it possible to bind a single ? in a parameterized query to a listing of values for an in clause? (artifact: d5deab1635 user: LarryBrasfield)

You can find source for the carray extension here. You can either include it statically into your build or create a loadable extension with that source. Until you do one or the other, 'carray' will probably remain an unknown identifier which, if used to reference a table, will produce errors such as you report.

2020-12-22
02:00 Reply: sqlite3_bind_text with SQLITE_STATIC and SQLITE_TRANSIENT (artifact: bacaa1ab02 user: LarryBrasfield)

Re use of SQLITE_STATIC and SQLITE_TRANSIENT, when using sqlite3_bind_text(), Gary asks:

If the pointer to the character array points to an area of managed/heap memory, should SQLITE_TRANSIENT always be used or can that memory space be freed in the usual manner at a later point elsewhere in the C code? Is SQLITE_TRANSIENT for convenience or is it mandatory?

Instead of worrying or asking about what sort of memory "the pointer to the character array" points to, you should answer the question, suggested in the doc for the sqlite3_bind_text() function), will that character sequence reliably remain accessible there, or might it be used for something else or become inaccessible as the SQLite execution engine runs the prepared statement? If the former, SQLITE_STATIC may be used to avoid an allocation, but if the latter, SQLITE_TRANSIENT must be used to ensure that an accessible copy is made. If you are managing the memory where that "character array" resides and can guarantee that the pointer to it remains useful while the execution engine runs, your scheme of taking over some of the memory management will work (if you do it right) and SQLITE_STATIC will do some good.

Your surmise about space required for bound variable values, and its relation to SQLite handling the memory allocation for the actual values bound raises the very issue that your previous question does. If you use SQLITE_TRANSIENT, SQLite will manage the necessary memory. If you use SQLITE_STATIC, SQLite will take you at your word that it need not make a copy into its own managed memory.

2020-12-20
12:20 Reply: multiple queries (artifact: 0ee25fd8e9 user: LarryBrasfield)

If you merely split on semicolons, consider how that scheme will treat this: select "silly;column;name" from "silly;table;name" where "silly;column;name" not like '%;%'

2020-12-19
20:14 Reply: multiple queries (artifact: 136572ee68 user: LarryBrasfield)

You might do a search on "parser" and "error recovery" (together.) As you will see, it is not a trivial task. I am not surprised that the SQLite parser has not been made to somehow figure out what should be consumed as erroneous while leaving what is maybe not.

If you insist on solving the problem, finding a statement separator not embedded in quoting delimiters is likely your best bet. You will need to replicate the SQLite scanner (or "lexical analyzer") for that.

I am curious as to what the application is that makes solving your stated problem preferable to just complaining about the whole conglomerated statement sequence.

2020-12-18
16:05 Reply: 'ON DELETE CASCADE' seems to not be working (artifact: ba6b2fd05c user: LarryBrasfield)

You have described, with some redundancy, why 'UNIQUE PRIMARY KEY' is redundant, or possibly, with surplusage, singly redundant. But I cannot see that it is either doubly redundant or a redundant redundancy, let alone a doubly redundant redundancy. However, I have to grant bonus points for well demonstrating pleonasm.

2020-12-16
13:45 Post: code typo (forwarded) (artifact: 958218fc25 user: LarryBrasfield)

In the Fossil forum, this apparent code typo was reported, where the preprocessor symbol SQLITE_AMALGAMATION was mistyped as SQLITE_AMAGAMATION.

11:05 Reply: printf improvement (artifact: 4e9dba841b user: LarryBrasfield)

Yes, a view, or a suitably ordered query, can serve some presentation purposes.

The problem with this line of reasoning [a] is that there is no end to the enhancements it can justify. The library is about keeping and retrieving data. It is arguable that it need not have a printf() function at all. I suspect that the reason it does is that the printf engine needed to be present anyway. (It is used for type conversion to string.)

[a. (Trying to avoid erecting a straw man here.) The reasoning seems to be that because the existing, non-extended SQLite library can produce sufficiently presentable output for some purposes, it should be considered a presentation tool and evolved for that purpose. ]

A more human reader oriented number formatting function can easily be created and added as an extension. Extension functions are readily added and can be statically linked with the SQLite library. Your number pretty-printer would be a nice contribution, for some users of the library.

2020-12-14
18:46 Reply: SQLite3 - Open & Attach (artifact: e0f8e40d76 user: LarryBrasfield)

The SQLite library normally arranges for putatively concurrent accesses to be done safely. Of course, you could always close that DB "handle" (which is just a pointer to a data structure) and have the same situation you originally implied.

18:15 Reply: SQLite3 - Open & Attach (artifact: e3905e0c42 user: LarryBrasfield)

Without contradicting Mr. Beal's response(s), I can say:

There is nothing preventing somebody from using a SQLite API for retreiving a filename from a connection, then attaching the named DB to another existing connection.

16:34 Reply: multiple queries (artifact: eb21c8fc7d user: LarryBrasfield)

I have no expectation of luck or desire to rely on it.

At the point I suggested, to the OP, a way of knowing how much of a multi-statement string was accepted by sqlite3_prepare, the "strings" are simple char* but known to be referencing UTF-8 code sequences. Computing the accepted number of "characters" (or UTF-8 code points) has nothing to do with C# at that level, with this tiny proviso: Once control gets back to the C# domain, where we can presume the multi-statement string appears as a CLR String type, it is quite easy to lop off the accepted portion using the .Substring(int startIndex) method, where that index is not a count of UTF-16 words but is a zero-based "character position". That .Substring() method can be safely used without having to anticipate that the UTF-16 encoding used for CLR String objects will result in some other number of characters being lopped off or that a UTF-16 code point representation will be sliced into pieces.

It is because zSql (and zTail) point to possibly multi-byte character representations that my suggested code did not do simple pointer arithmetic. Doing that might have worked, but only by luck. As we know, having something work by luck is often a form of bad luck.

15:55 Reply: multiple queries (artifact: 9f367ca903 user: LarryBrasfield)

I believe that zSql, and hence zTail also, are pointers to a UTF-8 code sequence. [a] The reason that I did not advise the pointer arithmetic you suggest is because it does not yield the number of characters consumed unless they happened to be restricted to the ASCII subset of UTF-8 code points.

[a. Per the sqlite3_prepare doc, zSql is "/* SQL statement, UTF-8 encoded */". ]

15:41 Reply: SQLite3 Extension (artifact: 202bdb6176 user: LarryBrasfield)

I got that very old, contributed extension to compile/link to a DLL which could be loaded as a SQLite extension without explicitly stating the entry point. To do that, I had to correct for two deviations in extension-functions.c from the guidance published as Programming Loadable Extensions. These deviations are:

(1) There is nothing to mark the sqlite3_extension_init() function as one to be exported as an entry point in the DLL, for which purpose the guidance recommends the preface: #ifdef _WIN32 __declspec(dllexport) #endif That alteration suffices to get the would-be entry point to appear in the output of dumpbin /exports .

(2) The sqlite3_extension_init() function's name does not adhere to the guidance suggestion, "You will do well to customize the name of your entry point to correspond to the name of the shared library you will be generating, rather than using the generic "sqlite3_extension_init" name." Unless the extension DLL happens to be named "extension.dll", this deviation will make it necessary to supply the actual entry point name as a second argument to the load extension call, (whether that be use of the .load command or the load_extension(X,Y) form of built-in SQL function.)

12:48 Reply: SQLite3 Extension (artifact: d065d52936 user: LarryBrasfield)

As Keith asks, dumpbin will show what your extension's init function was really called. Then you can compare that to the name that is generated when you do not specify it in the load extension operation, as documented in section 4, here.

You say you "compiled with these files ...", without leaving any clue as to what that means. The build guidance in section 3, here shows one possible meaning, known to produce a usable result. If you are doing something else, a careful study of how that differs from the guidance will likely be instructive. If you are using the Visual Studio IDE, you can see in one of its plethora of window panes how the command-line tools are actually being invoked. That likely differs in some critical manner from the guidance.

12:34 Edit reply: SQLite3.EXE (artifact: 7ba1d31140 user: LarryBrasfield)

(Edited to avoid backslash molesting in code block.)

The SQLite CLI shell does not have such a feature.

However, the following Perl program would tell you (if run by Perl.) my $usage = <<'_'; Usage: exetype <Exe-file> ... For each file named, emit one line giving its name and .exe machine type. _ use strict; use IO::Handle; use Fcntl 'SEEK_SET';

if (@ARGV == 0){ print $usage; exit(0); }

my %machineTypes = ( 0x0 => 'Other', 0x1d3 => 'Matsushita AM33', 0x8664 => 'AMD/Intel x64', 0x1c0 => 'ARM little endian', 0xaa64 => 'ARM64 little endian', 0x1c4 => 'ARM Thumb-2 little endian', 0xebc => 'EFI byte code', 0x14c => 'Intel/AMD i386+', 0x200 => 'Intel Itanium processor family', 0x9041 => 'Mitsubishi M32R little endian', 0x266 => 'MIPS16', 0x366 => 'MIPS with FPU', 0x466 => 'MIPS16 with FPU', 0x1f0 => 'Power PC little endian', 0x1f1 => 'Power PC with floating point support', 0x166 => 'MIPS little endian', 0x5032 => 'RISC-V 32-bit address space', 0x5064 => 'RISC-V 64-bit address space', 0x5128 => 'RISC-V 128-bit address space', 0x1a2 => 'Hitachi SH3', 0x1a3 => 'Hitachi SH3 DSP', 0x1a6 => 'Hitachi SH4', 0x1a8 => 'Hitachi SH5', 0x1c2 => 'Thumb', 0x169 => 'MIPS little-endian WCE v2' ); my $efh; my $coffOffset; foreach my $efn (@ARGV){ if (!sysopen($efh, $efn, 'O_RDONLY')){ print stderr "Cannot read $efn\n"; next; } binmode($efh); my $pos = sysseek($efh, 0x3c, SEEK_SET); my $nr = sysread($efh, $coffOffset, 2); if ($nr != 2){ print "$efn\tOther\n"; close($efh); next; } my $cos = unpack('S', $coffOffset); $pos = sysseek($efh, $cos, SEEK_SET); my ($peSig, $peNs, $machine); $nr = sysread($efh, $peSig, 2); $nr += sysread($efh, $peNs, 2); $nr += sysread($efh, $machine, 2); my $ns = unpack('S', $peNs); if ($nr == 6 && $ns == 0 && $peSig eq 'PE'){ my $mtype = unpack('S', $machine); my $mt = $machineTypes{$mtype}; if (!defined($mt)){ $mt = 'Other'; } printf("$efn\tPE(%s)\n", $mt); } else{ print "$efn\tOther\n"; } close($efh); }

2020-12-13
20:13 Reply: SQLite3.EXE (artifact: 033d792994 user: LarryBrasfield)

The SQLite CLI shell does not have such a feature.

However, the following Perl program would tell you (if run by Perl.) my $usage = <<'_'; Usage: exetype <Exe-file> ... For each file named, emit one line giving its name and .exe machine type. _ use strict; use IO::Handle; use Fcntl 'SEEK_SET';

if (@ARGV == 0){ print $usage; exit(0); }

my %machineTypes = ( 0x0 => 'Other', 0x1d3 => 'Matsushita AM33', 0x8664 => 'AMD/Intel x64', 0x1c0 => 'ARM little endian', 0xaa64 => 'ARM64 little endian', 0x1c4 => 'ARM Thumb-2 little endian', 0xebc => 'EFI byte code', 0x14c => 'Intel/AMD i386+', 0x200 => 'Intel Itanium processor family', 0x9041 => 'Mitsubishi M32R little endian', 0x266 => 'MIPS16', 0x366 => 'MIPS with FPU', 0x466 => 'MIPS16 with FPU', 0x1f0 => 'Power PC little endian', 0x1f1 => 'Power PC with floating point support', 0x166 => 'MIPS little endian', 0x5032 => 'RISC-V 32-bit address space', 0x5064 => 'RISC-V 64-bit address space', 0x5128 => 'RISC-V 128-bit address space', 0x1a2 => 'Hitachi SH3', 0x1a3 => 'Hitachi SH3 DSP', 0x1a6 => 'Hitachi SH4', 0x1a8 => 'Hitachi SH5', 0x1c2 => 'Thumb', 0x169 => 'MIPS little-endian WCE v2' ); my $efh; my $coffOffset; foreach my $efn (@ARGV){ if (!sysopen($efh, $efn, 'O_RDONLY')){ print stderr "Cannot read $efnn"; next; } binmode($efh); my $pos = sysseek($efh, 0x3c, SEEK_SET); my $nr = sysread($efh, $coffOffset, 2); if ($nr != 2){ print "$efntOthern"; close($efh); next; } my $cos = unpack('S', $coffOffset); $pos = sysseek($efh, $cos, SEEK_SET); my ($peSig, $peNs, $machine); $nr = sysread($efh, $peSig, 2); $nr += sysread($efh, $peNs, 2); $nr += sysread($efh, $machine, 2); my $ns = unpack('S', $peNs); if ($nr == 6 && $ns == 0 && $peSig eq 'PE'){ my $mtype = unpack('S', $machine); my $mt = $machineTypes{$mtype}; if (!defined($mt)){ $mt = 'Other'; } printf("$efntPE(%s)n", $mt); } else{ print "$efntOthern"; } close($efh); }

19:44 Reply: multiple queries (artifact: ce1583b3a4 user: LarryBrasfield)

public int RunOneStatement( SQLiteConnection db, string sqlGlom, out int charsUsed, ... ) { char * zSql = sqlGlom.?; rc = sqlite3_prepare_v2(db.?, zSql, sqlGlom.bytelength, & pStmt, & pzTail); step ...; finalize ...; charsUsed = 0; while (*zSql && zSql < pzTail){ // Advance zSql by one utf-8 code. ++charsUsed; } // Free zSql if necessary. }

The '...' in the signature would likely be a delegate to handle per-step actions that are needed. The '.?' methods are whatever it takes to get representations usable in native (or C) code.

This would enable the same sort of loop, consuming a single SQL statement per iteration, that you envisioned when you asked about getting/using pzTail. The difference here is that pzTail is still a valid pointer where used. At the C# level calling the above function, just lop off as many character codes as charsUsed indicates, or terminate the loop when it equals zero.

2020-12-12
19:13 Reply: multiple queries (artifact: 118b92e4cd user: LarryBrasfield)

The OP had claimed "/*I can get this */", which I elected to bypass because I suspect it is the same glutton for tedious work responsible for several other threads here lately. Using sqlite3_complete() would certainly work, albeit without the clarity one might like. Not glomming statements together from the outset would be clearer yet. Or, if the OP in fact is creating the C#/SQLite-C adapter layer, it would be very simple for it to have an out integer parameter which returns the number of characters consumed. Given that the zSql content is utf-8, computing that may take a bit more than pointer differencing, but it would be at least clean.

18:44 Reply: multiple queries (artifact: 2fc2de7271 user: LarryBrasfield)

To me that suggests that the pointer is still alive in the DLL. If that is the case, then an API to return the remaining portion of the SQL would be handy.

The pointer is nothing more than a single value, easily passed by value. The issue is whether that pointer points to something that can be referenced. My point is that is probably does not upon return to the C# call site. There is no way for a heretofore nonexistent SQLite API to later "return the remaining portion of the SQL" unless the connection were to store it away for future reference, which would also require a way to cease storing it. I would bet long odds against that happening, particularly because the existing API already permits the operations you would like to perform. (It does not support them in quite the manner you are thinking, but it does support the work-around that I suggested earlier.)

Your possibly neat workaround could be made to work. With very similar memory allocation, you could just extract the single SQL statements from the statement glom and do the prepare/step/finalize on each one. That would be more straightforward, IMO.

16:22 Reply: multiple queries (artifact: 58236284a4 user: LarryBrasfield)

This is more of a C# question than a SQLite API question.

That said, there is not going to be a good way to use that pzTail out pointer from the C# calling context. At the C API level, it will be pointing within the range of chars referenced by zSql. But at the C# calling level, the string parameter passed whose content ultimately becomes something referenced by a zSql is likely to be stored in a temporary whose lifetime expires before or during the return to the C# calling context. Hence, the pzTail value coming out of the C-level call will be referencing memory that likely will not be allocated to hold zSql content when the C# calling code regains control.

If you have control of the adapter layer between the C# interface and the SQLite C library, you could create there a new C# string reflecting the content portion referenced by pzTail, and make that an out parameter of the C# interface. The means of copying C string content to C# string objects should be easily found (and they are off-topic here.)

Is there an SQLite3 function to retrieve the string from the pointer **pzTail?

No. That would be a simple C expression too trivial to merit an API entry.

2020-12-09
18:09 Reply: Visual Studio Compile Issue (artifact: 99456f79d0 user: LarryBrasfield)

You are going to have to figure out what is going wrong with your build. The odds are astronomically against somebody here having seen or posted the same issue.

The Visual Studio IDE build system ultimately just runs the command line compiler, linker, etc. to effect its builds. You can consult the logs to see how those tools were invoked, including the compilation preprocessing flags. You may need to run the compile with those same flags, except with -E or -P to capture preprocessed output. Then you can "compile" that with a -Zs flag (for syntax checking only) to determine where in that largish "source" the first several of your errors arise. Then you need to find out why by studying where the complaint-inducing references to undeclared objects are made and where those objects were supposed to be declared. You may do some string searches among .c and .h files for relevant identifiers.

The -E or -P output shows where the #include files were found. You need to ensure that the SQLite libarary files are coming from a single release rather than some strange combination.

You will do well to turn off precompiled headers. That feature speeds compilation wonderfully, but it can get really messed up sometimes.

While I do not like to encourage big error dumps to this forum, or people throwing up their hands and hoping somebody else can sort out ordinarily messed-up build problems, I will say that your errors strongly suggest that the problem is very fundamental. In particular, to see an error, "'Blah': undeclared ...", when compiling the very source in which 'Blah' is declared prior to use, indicates to me that the examination of preprocessed output is due. The objects complained of that I checked are declared and used within preprocessor conditionals. Those declarations and usages appear to have coordinated conditions, suggesting that some cross-release source mixing is occurring.

2020-12-08
16:19 Reply: How to ignore "no such function" in metadata creation (artifact: b927a3136b user: LarryBrasfield)

You could put your "user functions" into an extension DLL and load it before creating views which use the functions. If you only wish to use sqlite3 for DDL, the functions would not even need to have real implementations; they could return NULL.

2020-12-07
15:20 Reply: libreadline problem with Ubuntu 20.04 (artifact: c2b98d58b3 user: LarryBrasfield)

Minor correction re:

a better option would be to build the amalgamation from source.

That is not necessary to resolve the problem(s) stated in this thread. All that is needed is to compile and link the CLI shell executable from the "amalgamation", a term which refers to certain .c and .h files which are pieced together from multiple sources in the VCS.

2020-12-06
21:30 Reply: sqlite3_close (artifact: 517502f0b5 user: LarryBrasfield)

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.

20:12 Reply: SQLite 3.34 binary not working on Ubuntu 20.04 (not found) (artifact: 7b976ba1f8 user: LarryBrasfield)

there should be a very clear hint ...

For future reference: In the archive filename, "sqlite-tools-linux-x86-3340000.zip", the '-x86-' means it is for 32-bit Intel CPUs such as i486, i586, (or i386 if you have one.)

Of course, that may be too subtle a hint for some, although this naming convention has been widely adopted.

if there were two versions - 32 and 64 bit - that would be ideal.

It would be more convenient for some. And I would agree that, these days, a 64-bit image (aka '...amd64...') would be more useful than the 32-bit one. But I have always seen provision of prebuilt executables as a convenience rather than cause to be making a bunch of "should" pronouncements regarding the gajillion architectures for which no prebuilt images are provided.

17:04 Reply: SQLite 3.34 binary not working on Ubuntu 20.04 (not found) (artifact: c2c2731991 user: LarryBrasfield)

On my very recent version of Ubuntu 20, attempting to execute that 32-bit image from bash produces: cannot execute binary file: Exec format error , which is clearly different from the "not found" in your thread title, and from the "No such file or directory" in your post #1, and from "Sorry, but no. The behaviour is the same." in your post #3.

If you want effective and efficient help here (or any other forum), you need to be accurate with your reports of the problem symptoms and context.

As for why the SQLite devs publish a 32-bit image, Ubuntu has only recently stopped offering 32-bit builds, as of the v20 release.

As for why "the system doesn't give a proper message saying that a 32 bit executable cannot be run on the current system.", you would have to ask in a Linux forum. In my opinion, the message I quoted above is a proper message indicating that the "binary file" does not have a format known to the loader. I think it would be beyond the call of duty, once that determination is made, for it to examine the file attempting to guess what it is and educate the user. After all, there is the wonderful 'file' program that knows how to do that. The loader's complaint is surely enough to trigger the error-instigator's question, "Well then, what is that binary file?". Maybe the loader's author's can be persuaded to add something like a tip referring to the 'file' program. (But that is not generally the *Nix way.)

14:57 Reply: sqlite3_close (artifact: f93e428745 user: LarryBrasfield)

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.

  1. Are you using the SQLite C library directly from C#?

  2. If yes, how? [a] If no, via what adapter library?

  3. 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.

2020-12-05
20:31 Reply: SQLite 3.34 binary not working on Ubuntu 20.04 (not found) (artifact: 5f745f5b19 user: LarryBrasfield)

In what directory did you put the latest sqlite3 executable?

Does that directory appear when, in bash, you enter: echo $PATH

Here are commands entered (to bash) in a Ubuntu 20 session just now: sudo apt install gcc sudo apt install automake sudo apt install make cd sqlite-autoconf-3340000/ ./configure make sudo mv sqlite3 /usr/bin/ which sqlite3 sqlite3 , which (after omitting much install and build verbosity) yields: SQLite version 3.34.0 2020-12-01 16:14:00 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite>

I had to build because the 32-bit executable for Linux cannot be run on my 64-bit system, at least not conveniently.

01:50 Reply: Setup of SQLite on windows (artifact: 834a7f6935 user: LarryBrasfield)

I assume you are asking how to setup the SQLite CLI shell. From the Download page, get the .zip archive described as "A bundle of command-line tools for managing SQLite database files". Select a directory named in your PATH environment variable, or create one and add it to that variable. Then extract the archive content to that directory. At that point, from either a CMD.exe shell or a Powershell session, you should be able to invoke 'sqlite3' to start the SQLite CLI shell.

If you mean something else by "set up SQLite", you will need to learn programming before you can expect to make use of the SQLite library. By the time you do that, details of getting it setup will be more obvious.

Have fun.

2020-12-04
02:05 Reply: Support of unicode operators like ≠? (artifact: 400b9a1ff5 user: LarryBrasfield)

That is Apple's name for the Alt key. Innovation!

2020-12-03
15:08 Reply: Is typeof() and hex() unique ? (artifact: 673dd6caef user: LarryBrasfield)

To me, as someone who read the hex() documentation, that intermediate text conversion comes as a real surprise. Would you not agree that this detail is worthy of some explication in that function's description?

Is there any simple way to achieve Simon's objective?

14:44 Reply: Is typeof() and hex() unique ? (artifact: f0e215e5d8 user: LarryBrasfield)

On v3.34.0, that last query returns ieee754(3602879701896397,-50) ieee754(3602879701896397,-50) , which are so subtly different that I can see no difference whatsoever.

If what you say is true, then what is the meaning of the claim made for hex() that it "interprets its argument as a BLOB and returns a string which is the upper-case hexadecimal rendering of the content of that blob"? Are you saying that there can be content which somehow escapes being rendered into hexadecimal by the hex() function? And, if that is true, I would claim that the quoted documentation is incorrect.

14:08 Reply: Is typeof() and hex() unique ? (artifact: e8f48ba0f5 user: LarryBrasfield)

The hex() function converts whatever byte sequence represents the value into hexadecimal, so it must vary when the value varies. The typeof() function produces a text form of the value's type as stored in the DB. Hence, of course the combination is unique for any given value and type.

If there was a circumstance where that was not true, it could only happen due to a bug in SQLite.

11:51 Reply: Can't Insert the column data to a table (artifact: 4de275cad6 user: LarryBrasfield)

While I could not completely puzzle out your paragraphs beginning with "The issue ...", I did notice that your insert statement has what appears to be intended as a string literal but which, because it is not single-quoted, is an identifier.

If you really are getting a SQLITE_CORRUPT return from the SQLite library, it means either you have a corrupt database or you have passed something to the SQLite API that was supposed to be a pointer to its database structures but was not. Either way, the library tends not to corrupt its own databases absent problems such as heap corruption or having its own data walked upon by other code.

It is impossible to reasonably guess at your root cause from what you have shown. For one thing, "sqlite3InitCallback(...)" is not a SQLite API, so it must be yours, doing who knows what. It is anybody's guess as to why it returns the string "initData.rc = SQLITE_CORRUPT". Or do you mean to say that initData.rc equals the API constant SQLITE_CORRUPT? I could believe that, but without seeing its code I cannot guess as to why.

BTW, Please use the HTML code tags to delimit your code in posts. For example:

<code> This is my code, without interpretation as markup. </code>

11:22 Reply: Nulls or blanks (artifact: 9011146508 user: LarryBrasfield)

It is an acronym for Original Poster.

2020-12-02
18:53 Reply: SQLite - CLI History dialogue (artifact: e757a520bb user: LarryBrasfield)

Your supposition is bound to be disappointed as it is based on a false analogy.

The "command prompt window", (by which I presume you mean the cmd.exe program running as a process with connections to a conhost.exe (or, lately, a WindowsTerminal.exe)) process which provides a character based console-like window, makes use of features that go beyond simple reads from the stdin stream and writes to the stdout stream. The sqlite3.exe shell, built from shell.c, does very few platform specific or unique I/O.

There are several ways this could be "overcome". One would be to use the readline library (or whatever equivalents are available on Windows) instead of relying on that F7 popup feature which is unique to Windows. Provisions are already made for use of that library. (I have used them myself.) Another would be to write some code, preferably presenting the same application interface as the readline library, which would, conditionally for Windows, adapt that misplaced [a] conhost.exe functionality to effect the critical readline functions. Finally, you might persuade or shame some SQLite developer(s) into doing the latter. (I predict failure for that last option; I include it for completeness.)

[a. Putting line editing in the console is good for the crudest kind of line recall and modification, but it is the wrong place for anything as useful as context dependent token completion. So I see that as misplaced in conhost.exe and its modern successor. ]

15:47 Reply: Nulls or blanks (artifact: f5bdbc730e user: LarryBrasfield)

Using trim() might be better, depending on what the OP's data means. I had the impression that the difficulty was more fundamental. And because there are few ways of acquiring data that result in space sequences, I thought to not complicate things any more for the OP.

14:09 Reply: Nulls or blanks (artifact: 9f71a8100a user: LarryBrasfield)

Have you tried adding something like where MotherID=0 or MotherID='' or MotherID is null; ?

2020-12-01
02:36 Reply: Get the database busy when create a table (artifact: 1a0d09f5d0 user: LarryBrasfield)

I would look carefully to see if Warren's idea (in post #3) applies. It is a common error for early users of SQLite to neglect to call finalize() after getting the useful work done with a prepared statement. If this is your problem, it would be a problem on any platform, independent of your VFS implementation.

2020-11-30
17:54 Reply: CLI shell history (artifact: 6aaa0dc85f user: LarryBrasfield)

The SQLite CLI shell provides no way to clear the history. It keeps the history internally (in process memory), so nothing you do to its persistent form will affect that for the readline library written as it is today.

You may want to consider using one of the many excellent GUI tools for manipulating and querying SQLite databases. Maintaining a set of save queries is an extremely common feature in such tools. The CLI shell is not really meant to be a deluxe tool. It is more of a bare-metal interface to the SQLite library, (although less so than in years past.)

14:17 Reply: Get the database busy when create a table (artifact: 49515960a8 user: LarryBrasfield)

A couple possibilities:

  1. Your VFS is not as OK as you think, and its mutex provision is flawed such that the mutex release does not work. Did you test it carefully?

  2. It should be relatively easy to put breakpoints on your VFS mutex related entry points and see what is happening. Until you have done that, it is quite premature to be asking for guesses as to what has gone wrong. After all, SQLite works on quite a few platforms already, making yours most likely to be what is different. And given that, guesses obtained from this forum are bound to be random, no better than your own.

BTW, your 'varchar(32)' as a data type probably shows a missing understanding of SQLite's type scheme. If you are doing that to save storage, it is unnecessary (and useless.)

More ↓