SQLite Forum

Timeline
Login

50 forum posts by user larrybr occurring on or before 2021-09-23 15:32:05.

More ↑
2021-09-23
15:32 Reply: sqlite not working on alpine arm32 image (artifact: 071ea602f1 user: larrybr)

What would be the first of 20 questions? (I ask rhetorically.)

Have you tried the build by following guidance at How to Compile SQLite?

If not, try that.

If so, how did that go wrong?

What is it that you are trying to build?

What does "not working" mean in terms of specific inputs, actual outputs, and your expectation regarding outputs?

One idea I have is: SQLite works on ARM and has for quite some time. So I imagine you are doing something differently that suggested at above link. With more information, I and other would have a basis to say what you are doing differently that leads to your disappointment.

13:29 Reply: launch backup_malloc.test error (artifact: fc40d1fec9 user: larrybr)

The issue you report does not appear to exist with v3.37.0 (in alpha now.)

Furthermore, the test/backup_malloc.test has not been modified as you suggest for that coming release, and I do not think it should be. Among the "features" tested is not leaking memory in the face of unusual OOM situations.

11:17 Edit reply: cannot start a transaction within a transaction using sqlite shell (artifact: 2bd961a88a user: larrybr)

(Edited to retract earlier agreement and amend earlier experiment report)

After looking into this, I no longer agree that your test should have either succeeded, without the complaint you posted, or should have done something else. (I would think it would have "failed" often with a flurry of "busy" messages. This I expect because, by default, there is no busy handler set by the shell. The shell indicates this with a message, "Error: near line 18575: database is locked". )

With sqlite3 v3.36.0 on Ubuntu, instead of the error you report I get Error: near line ###: disk I/O error , repeatedly, where the line number progresses.

I think this also should not happen. This will be investigated.

This does not happen on Ubuntu 20.04 running on a system by itself. It appears to be an artifact of running on Ubuntu WSL.

(Amendment via edit in light of Richard's post:)

With this in the DB stuffing process: for n in $(seq 1000000); do echo "begin immediate transaction; insert into foo values($n); commit;"; done | sqlite3 test.db , I continue to get the "disk I/O error" on WSL only.

I agree that letting SQLite defer actual transaction until the next, does-something statement, is problematic. I am investigating why, without such deferment (using "immediate") there is still an error other than SQLITE_BUSY.

11:06 Reply: sqlite3_sql return value (artifact: ced877e1fc user: larrybr)

You may have noticed a parameter, pzTail, in the sqlite3_prepare() signatures. The prepare operation only operates upon one SQL statement at a time, but if you ask for it (by setting the pzTail pointer to reference a char *), the prepare will let you know where the remainder of your submitted string begins.

What you see is correct. See the prepare doc.

11:00 Reply: cannot start a transaction within a transaction using sqlite shell (artifact: f6ffffcd92 user: larrybr)

I agree that that is what is happening, but I don't think that's what's supposed to happen.

Supposing is a funny thing, kind of like beauty being in the eye of the beholder. I suppose, (and I'm pretty sure Richard supposes), that what you are seeing is exactly what has been designed to happen. I believe your supposition needs to adapt to what Richard has said is likely happening, which is occurring in detail for the reason Keith says (and I confirm.)

My understanding was that transactions are distinct to an individual process.

Processes have nothing to do with it, except as something which affects implementation of the documented behavior (which is what you are seeing.) SQLite "connections" (aka pointers to opaque sqlite3 objects) are what map one-to-(zero or one) to transactions.

Also, note that even with the DELETE running in an explicit transaction, the same thing happens.

Whether the other connection interfering with your insert sequence is working under explicit or automatic implicit transaction has no bearing on the problem. The same thing is happening with that connection's access to the DB either way.

Looking at the documentation [about transaction concurrency]

This has no bearing on the problem you see. The problem here is relatively simple, with the main complication arising from how the shell processes statement groups.

01:59 Reply: sqlite_master -> sqlite_schema rename breaks DB dump compatibility (artifact: d45dbfbc3d user: larrybr)

One perhaps brutal way: .once |sed -e s/sqlite_schema/sqlite_master/ > archaic_dump .dump , which will also alter any text or goofy identifiers containing the modern name for SQLite's schema table. (Maybe that's for the best.)

01:37 Reply: cannot start a transaction within a transaction using sqlite shell (artifact: 524bd6dc80 user: larrybr)

This ENTIRE bufferload consisting of THREE STATEMENTS is sent to the CLI for execution. However, the execution had an ABORT at the second statement in the batch; thus, aborting the batch. The COMMIT; statement was never executed.

I confirm this is how the shell handles "grouped" SQL statements.a By "grouped", I mean when each SQL input line either contains one or more semicolon-separated statements terminated by a semicolon, or ends with an open construct, such as a quoted string or identifier or a block comment which does not have its terminating token such that one or more additional lines are collected into the "group" before it is submitted to the library for execution (prepare(), step(), etc.) For example, this would be a group: INSERT INTO Fiddle VALUES (1) /* and more! */ ,(2) ('and more'); SELECT * FROM Fiddle;

The bottom line is just as Keith says: Failure on one statement within the group precludes execution of latter statements within the group.


a. I confirm that general sense of the processing. But I would not say anything "is sent to the CLI for execution" except in the sense that the CLI accepts whole lines at a time. Whether or not lines are given over to the SQLite library for execution is determined by the CLI's own logic.

2021-09-22
19:54 Edit reply: cannot start a transaction within a transaction using sqlite shell (artifact: d13843e73b user: larrybr)

I agree that your test should have either succeeded, without the complaint you posted, or should have done something else. (I would think it would have "failed" often with a flurry of "busy" messages. This I expect because, by default, there is no busy handler set by the shell.)

With sqlite3 v3.36.0 on Ubuntu, instead of the error you report I get Error: near line ###: disk I/O error , repeatedly, where the line number progresses.

I think this also should not happen. This will be investigated.

(Amendment via edit in light of Richard's post:)

With this in the DB stuffing process: for n in $(seq 1000000); do echo "begin immediate transaction; insert into foo values($n); commit;"; done | sqlite3 test.db , I continue to get the "disk I/O error".

I agree that letting SQLite defer actual transaction until the next, does-something statement, is problematic. I am investigating why, without such deferment (using "immediate") there is still an error other than SQLITE_BUSY.

19:42 Reply: cannot start a transaction within a transaction using sqlite shell (artifact: 9add7d62fb user: larrybr)

I agree that your test should have either succeeded, without the complaint you posted, or should have done something else. (I would think it would have "failed" often with a flurry of "busy" messages. This I expect because, by default, there is no busy handler set by the shell.)

With sqlite3 v3.36.0 on Ubuntu, instead of the error you report I get Error: near line ###: disk I/O error , repeatedly, where the line number progresses.

I think this also should not happen. This will be investigated.

15:07 Reply: Windows thinks 64bit SQLite3.dll is 32 bit (artifact: 009f5d68c6 user: larrybr)

There is no setting of the "bitness" in the build process for Windows-targeted images except for the usual PE header that results (without any explicit instigation) from specifying the target machine/architecture to the compiler.

It would be completely superfluous or dead wrong to replace any part of the PE header with something that did not match the target for which all the contained code was compiled.

As other posters have suggested, your problem solution lies elsewhere.

14:44 Reply: sqlite3_exec: 5th parameter (artifact: 6fdc033bd0 user: larrybr)

Is the 5th a verbose description of the return code of sqlite3_exec?

Considered as an optional out parameter, yes. Technically, it is where the caller will receive a pointer to such an error message, at caller's option.

Should I check the 5th parameter (which is a C# out parameter) all the time or only when the return code is not SQLITE_OK i.e. 0?

It need not be checked at all; the int return indicates success or other outcomes.

sqlite3_exec() is a convenience function, wrapping a series of other calls, including potential retrieval of text error messages.

00:39 Reply: Question about UPDATE with LIMIT (artifact: 54774f1243 user: larrybr)

Something like: UPDATE feeder SET quantity = quantity + 1 WHERE id in ( SELECT id from feeder WHERE quantity < 200 AND available = 1 LIMIT 1 ) RETURNING id, food_weigth, quantity

2021-09-21
23:50 Reply: Queries across databases (artifact: aa286f302c user: larrybr)

Have you tried that same SQL, as the C# literal "attach database 'c:/sqlite/db/contacts.db' as contacts"? And if not, why not? If the shell which is published by this project (and produces "sqlite> " as its prompt) accepts your SQL, you can be reasonably sure that SQLite3.DLL will accept it (or should if it is built with this project's source.)

Going beyond your posed question: How are you "using SQLite3.DLL with C#"? That DLL does not present an interface easily used from C#, and the substantial work necessary to use it that way creates many learning opportunities. So if you have tried the obvious 2nd argument to sqlite3_exec() without success, you will need to provide much more detail before you can reasonably hope for help here.

21:47 Reply: Number=Number (artifact: 486e72e5f9 user: larrybr)

The issue you are having will probably become clearer once you compute and display the difference of your (allegedly) equal values. My wager is on the results not being zero as normal mathematics would require.

Should that be the case, and even if not, you should understand "What Every Computer Scientist Should Know About Floating-Point Arithmetic" if you are going to be using floating point values. Scheme has a better name for them, which is "inexact".

21:35 Reply: Compiling FILEIO.C (artifact: af2196c7f3 user: larrybr)

Thanks for sorting it out.

It either needed fixing or an apologetic/caution against using it like the other extensions in just one context. Fixing won.

I'm curious: why aren't compiled extensions ... included in the downloads? Especially FILEIO.DLL as it is built-in SQLite3.EXE but omitted in SQLite3.DLL.

The SQLite library is the main, supported product here. That is what is made conveniently available at the download page.

SQLite.exe and SQLite.dll differ more than how they are (normally) loaded. The former is the CLI shell, an application which uses and is linked against the library. The latter is just the library. There is much in the shell, including other extensions, that is not compiled into the dropped library images.

The extensions tend to be much more stable than the library and the shell. And they have less usage (I surmise.) So it is not evident that publishing binaries for the extension set across the supported platforms is worth the extra clutter on the download page and extra work required to create them. This could change some day, but nobody should hold their breath until then.

20:16 Reply: sqlite3 CLI .expert mode returns “Error: not an error”, if suggested index name is created, but does not match suggestion (artifact: 04a32e39ba user: larrybr)

Thomas,

Among the other noise, there should have been thanks for reporting the problem. Please accept my belated: Thanks.

The problem is fixed on trunk, as of this checkin. Please let us know of any more strange corners of the .expert input space that you find infested.

17:04 Reply: create taable with syntax error works ? (artifact: 0a1cfad38b user: larrybr)

... there's a bug ... where its quite plainly syntactically incorrect

It's not a bug. The behavior is plainly and clearly documented at the doc pages I linked above to help you understand that the behavior conforms. In particular, the last syntax chart I linked shows that your odd spelling of a typename should be expected to be accepted by the parser, and the type affinity determination rules (linked earlier) reveal that it should survive semantic processing also.

SQLIte is flexible but shouldnt there be SOME kind of error when there a pretty obvious syntactical issue like this ?

What is pretty obvious to you is not as simple as you imagine. The typename acceptance laxity is a convenience for those migrating SQL constructs from Na other DBMSs to SQLite. Across that set of other DBMSs, a wide and fluctuating variety of typenames are legal. I would grant that, as wetware operators, we humans can generally recognize the trying-to-be-a-typename subset of names, but it is unreasonable to expect SQLite to do that. It would be a maintenance headache, and a death-by-dribbles ongoing "bug" source.

In several weeks, the STRICT option will be available. The set of accepted typenames for tables with that option is very small (as another link I provided above shows.) So you should use that if it is too hard to remember to separate your column definitions as SQL requires.


a. N is an unknown and unbounded number.

13:44 Edit reply: sqlite3 CLI .expert mode returns “Error: not an error”, if suggested index name is created, but does not match suggestion (artifact: 5c756e3da3 user: larrybr)

The output should be "(no new indexes)" instead of that cryptic error, right?

Not necessarily. Only if the modified index actually results in a presumably optimal plan.

Now I feel confused. I thought that was precisely the case with your usage where you got a strange rather than useful or expected response.

At this example session, when the index exists that .expert mode would suggest were it missing, it is supposed to say "(no new indexes)". And if I understand your repro steps, it produces that strange-but-humorous error instead.

If you disagree, please show the sequence of SQLite shell commands that induces the error. (I thought you already had. I'm not trying to be difficult here; maybe it's time for more coffee.)

(Append via edit to resolve confusion:)

Ok, now I see that the index you added is subtly different from the one proposed. I guess I need to read more carefully. Now I agree that this is a bug, not cured by simply improving an error message.

13:34 Reply: sqlite3 CLI .expert mode returns “Error: not an error”, if suggested index name is created, but does not match suggestion (artifact: 3e46370576 user: larrybr)

The output should be "(no new indexes)" instead of that cryptic error, right?

Not necessarily. Only if the modified index actually results in a presumably optimal plan.

Now I feel confused. I thought that was precisely the case with your usage where you got a strange rather than useful or expected response.

At this example session, when the index exists that .expert mode would suggest were it missing, it is supposed to say "(no new indexes)". And if I understand your repro steps, it produces that strange-but-humorous error instead.

If you disagree, please show the sequence of SQLite shell commands that induces the error. (I thought you already had. I'm not trying to be difficult here; maybe it's time for more coffee.)

13:06 Reply: sqlite3 CLI .expert mode returns “Error: not an error”, if suggested index name is created, but does not match suggestion (artifact: f61823a481 user: larrybr)

Yes, that error message is anti-tautological.

The output should be "(no new indexes)" instead of that cryptic error, right? In other words, no new index should be proposed if I understand your scenario.

12:10 Reply: "box" mode ignores "headers" settings - headers is always "on". Bug? (artifact: 9944a668b3 user: larrybr)

Thanks for the report. This behavior is by design for column, markdown, table and box output modes; at least for now. (Reports of hardship resulting from this are welcome.)

11:53 Reply: Compiling FILEIO.C (artifact: 3a9ea35a01 user: larrybr)

Repeated the compilation with the new FILEIO.C. Passed. DLL is the same size as with the previous method of compilation.

Without FILEIO_WIN32_DLL defined, the preprocessed code is unchanged substantively. (Only whitespace and #line directives will differ.) So only debug builds could differ in size.

Repeated my tests with the new FILEIO.DLL. [(using -DFILEIO_WIN32_DLL)] Passed.

Thanks for verifying (and for the CL options carification.)

I noticed that the new FILEIO.C has the same date, namely, 2014-06-13. Should this change?

The headings of files in the repository are left alone as the source evolves.

2021-09-20
20:37 Reply: Compiling FILEIO.C (artifact: 3bdceb1bdd user: larrybr)

I have checked in a revised fileio.c which better accomplishes the effect of the separate source I posted earlier in this thread.

The fileio.dll extension can now be built thusly: CL -Os -DFILEIO_WIN32_DLL fileio.c -link -dll -out:fileio.dll , (assuming that a suitable vc_vars??.bat is run first as discussed earlier.) It is still necessary to have test_windirent.c, test_windirent.h, sqlite3ext.h and sqlite3.h in the same directory as fileio.c (or made #include'able via CL.exe's -I option.)

I would appreciate it if you could use that source to build and verify satisfactory operation of the fileio extension.a Please post results, positive or otherwise. (And consider it payback for the technical help.)


a. The resulting image has a slight improvement: The extension code which traffics in heap allocated objects with the SQLite library will use the same allocator that has been used by default or designated for the library's use via sqlite3_config. This defaults to malloc() and its cohorts, so this improvement will usually have no effect.

17:53 Reply: Database anomaly (artifact: 671b1e0957 user: larrybr)

... what this means is that ...
To me, that does not make any sense. Any insights?

It is quite possible that the code whose execution precedes the misbehavior you observe induces the (ill)famed "undefined behavior" well known to mortal C/C++ programmers with much experience. Whether that inducement is in your code or in the image you loaded that came from a semi-mysterious source is not clear.

I have found that making sense of undefined behavior can be quite challenging at times, requiring careful use of a debugger and inordinate time expenditure. It is best to just avoid it, or find where it is induced and fix that.

It would take much more evidence to convince me that it is worthwhile to attempt to diagnose your ex-problem without source for the mystery DLL you found.

15:23 Reply: Database anomaly (artifact: ea89b1ba88 user: larrybr)

Simon, If you sift through the thread, and its follow-ons, you will see that the OP's troubles were caused by using a strange DLL of unknown provenance.

15:16 Reply: Compiling FILEIO.C (artifact: 69698d8789 user: larrybr)

I'm just responding to a few minor issues, quoted.

[reporting file size] 148,992 fileio.dll
Larry, I'd be interested to know how the size compares with the size of your FILEIO.DLL.

I get your size with latest VS2019 compiler targeting x86 and 178688 bytes targeting amd64.

Step 1 Start Command Prompt as Administrator

That is not necessary. Ordinary privilege is all that is needed.

Step 2 ... Step 3 ...

There is a VS2019 (and earlier) installation option to provide Start menu shortcuts that accomplish all that with two clicks and some mouse motion.

... need to tidy up ... Deleted FILEIO.*

It is odd to delete fileio.c and no other sources.

... Tested FILEIO.DLL from my preferred location with success.

I was unable to discover how that fileio.dll you found was built when I perused the site where you were told to find it. This makes me wonder what it really was.

Hopefully, this experience will save me (& others) time when compiling other extensions.

Most (or maybe all) other extensions are as easy to build as is suggested at Compiling a Loadable Extension.

I will ponder how to warn about the extra considerations for fileio.c when built for WIN32.

thank you

You're welcome. We intend that this is somewhat easier than you experienced.

13:22 Reply: How to find out whether a table is STRICT? (artifact: 3d6204a6fa user: larrybr)

One of the virtues of SQL is that newly added columns do not have to be hidden to retain compatibility with existing, sensible queries. (Use of '*' as the projection criterion, then using the column names programmatically, is not sensible.)

12:58 Reply: Compiling FILEIO.C (artifact: 8c4bd2a1e8 user: larrybr)

Attempt 1: ...
fatal error C1034: ??.h: no include path set

The single-line, compile/link invocation works if my advice in post 2 is followed. Without that environment variable setup, the CL.exe compile/link driver does not know where to find system include files and libraries unless they are (tediously and laboriously) specified at each tool invocation. (Avoidance of the tedium and labor, and the study needed to perform it, is why the batch files and shortcuts to them exist.)

Attempt 2: ...
... error LNK2005: ... already defined in ...

The post in which I embedded utf8_to_wide.c advised this build method: Build thusly on Windows using the MSVC development tool set: CL -Os utf8_to_wide.c -link -dll -out:fileio.dll . Note that a single translation unit is compiled. A glance at that code shows that it #include's a couple of other sources directly. If you additionally compile those and attempt to link the resulting object files, you are bound to get multiple-definition errors.

If you really want to use your IDE to individually compile the C sources and link the results, you will need to do at least this to utf8_to_wide.c: (1) Remove the #include lines which incorporate fileio.c and test_windirent.c into the same compilation; and (2) Add one or more #include lines to bring in headers that fileio.c had itself #include'd. Then you will need to set preprocessor symbols for each of the 3 translation units equivalently to what utf8_to_wide.c had arranged as it caused them all to be compiled. (There may be a single set of values that works for all 3, or they may have to differ; I don't know.)

Now I must say something that might seem unkind (but is not:) If you are intent on being a software developer, you must learn to read and understand error messages that come from the tools you use. Bringing each little tool complaint to a forum where other participants are willing and able to do that is not a workable approach. A web search for the portions of error messages not specific to your project(s) may be illuminating as you initially learn what they mean. But the errors that have appeared in your threads here are very fundamental -- so much so that you should be making your own effort to discover what they mean. That is how you will progress up the learning curve.

02:18 Reply: Suggestion to support gzipped text in vsv extension (artifact: 513757a35b user: larrybr)

Victor, or Keith:

Could one of you please briefly describe, in black-box user's terms, what this enhancement to the vsv extension does?

I get from the posted patch that the input stream can be compressed. What I do not see without digging a lot further is whether ordinary uncompressed delimited files can still be used. (Does this depend on a magic header?) It is also unclear what compression utility produces the now-usable compressed input streams.

Given the ubiquity of delimited text data representation, this looks likely to be useful to others here if only they can see what it does.

Thanks.

02:02 Reply: Compiling FILEIO.C (artifact: e89f920505 user: larrybr)

Compiling is not as straight forward as made out here.

True. I am about to add an expando-tip to that "usually works" claim. It's author and I are not accustomed to using computers which do not have a compiler, linker, library manipulator, debugger, symbol table dumper, and other tools available with a few keystrokes at a command line shell. So read "usually" as "usually for the supposed target audience."

Given that tool setup described in post #2, fileio.c is still not going to build as easily as described in Compiling A Loadable Extension. This is unusual because fileio.c, when built for WIN32, has (apparently) been designed to link against a semi-public API of the SQLite library. (See sqlite3_win32_utf8_to_unicode if curious.)

To build a standalone DLL for WIN32, this code can be used:

/* utf8_to_wide.c . Fixup for SQLite project's ext/misc/fileio.c extension which appears to require static linking with the SQLite library to get one function that is unavailable otherwise and reuse several of that library's functions which are available from the C runtime. This wrapper provides the said unavailable function and #define's the others to use C runtime versions. This allows the extension to be built and used as a DLL. . Build thusly on Windows using the MSVC development tool set: CL -Os utf8_to_wide.c -link -dll -out:fileio.dll . In addition to this file, these 3 project sources are required: https://www.sqlite.org/src/file?name=ext/misc/fileio.c&ci=trunk https://www.sqlite.org/src/file?name=src/test_windirent.c&ci=trunk https://www.sqlite.org/src/file?name=src/test_windirent.h&ci=trunk */ #undef sqlite3_win32_utf8_to_unicode #define sqlite3_win32_utf8_to_unicode utf8_to_utf16 #include "fileio.c" /* Replacement for SQLite library API: */ LPWSTR utf8_to_utf16(const char *z){ int nAllot = MultiByteToWideChar(CP_UTF8, 0, z, -1, NULL, 0); LPWSTR rv = malloc(nAllot * sizeof(WCHAR)); if( rv!=0 && 0 < MultiByteToWideChar(CP_UTF8, 0, z, -1, rv, nAllot) ) return rv; free(rv); return 0; } #undef sqlite3_malloc #define sqlite3_malloc malloc #undef sqlite3_free #define sqlite3_free free #undef sqlite3_stricmp #define sqlite3_stricmp stricmp #include "test_windirent.c"

After saving the above as utf8_to_wide.c in some directory, and placing sqlite3.h, sqlite3ext.h and the 3 above-referenced sources in that same directory, see its heading comment for the one-liner build invocation.

2021-09-19
20:56 Reply: Compiling FILEIO.C (artifact: 188a920d07 user: larrybr)

You need to first run one of the batch files installed along with Visual Studio in recent years, shortcuts to which are labeled something like "Open Visual Studio 20xx Tools Command Prompt for targeting ..." and appear in the "Start" menu under "Visual Studio 20xx". These shortcuts run something like "...VCAuxiliaryBuildvcvars??.bat" in a cmd.exe session. This leaves a number of environment variable set, such as INCLUDE, LIB, LIBPATH and PATH which makes the Microsoft Visual C/C++ command line tools (CL.exe, LINK.exe, LIB.exe, NMAKE.exe) conveniently usable. (SQLite project makefiles for that toolset are designed with this setup presumed.)

You will need to have "sqlite3ext.h" reachable by the compiler, either in the current directory or findable among the paths named by the INCLUDE environment variable. This header is included with the amalgamation.

The environment variable setup done per above will also cause various link libraries to be findable by the compiler/linker that is run as CL.exe ; these should permit the link phase, which happens when the simple, one-line build procedure is used, to succeed.

The above-described arrangement, where "CL" just works (usually), is not unique to SQLite. A great many software builds can be effected the same way, by naming the files to be compiled and linked to the CL.exe driver.

18:07 Reply: Database anomaly (artifact: 9ca1a9b3db user: larrybr)

I acquired fileio.DLL from ...

That was an act of faith.

Can I get hold of fileio.DLL from somewhere else?

I should hope so. See the fileio source and Compiling a Loadable Extension.

16:11 Reply: Database anomaly (artifact: be04f31b63 user: larrybr)

Are you passing a Unicode pathname to sqlite3_open()? Maybe you need to call sqlite3_open16(). Or, if you're calling sqlite3_open_v2(), a WideCharToMultiByte() conversion may be needed.

15:46 Reply: Database anomaly (artifact: eb847b2a1c user: larrybr)

Thanks; I opened the initial database using an absolute path, namely,
d:sqlite32dbajay.db

I suggest sidestepping a host of "what is the pathname seen by library?" issues by using this pathname to the sqlite3_open call: D:/sqlite32/db/ajay.db . (It has been ages since anything called "Windows" actually required backslash as the path-part separator.)

Your (and our) focus needs to be on what pathname is actually reaching the SQLite API. A debug print of it may be illuminating.

15:18 Reply: Database anomaly (artifact: be0738ff50 user: larrybr)

First, discover what the "current directory" is for the process that uses v3.36 progrramatically. Then look at ajay.db in that directory and observe your "lost" change.

Second, specify the absolute pathname (rather than a relative pathname) to the database your program should be accessing.

If the terms "absolute" and "relative" make no sense to you in this context, do a web search for "relative pathname" and study the difference.

Why is my change not in the database I opened?

Your question presupposes a fact not in evidence. What, exactly, is "the database [you] opened"?

2021-09-18
13:39 Edit reply: sqlite3_step after sqlite3_finalize: what is the expected behavior? (artifact: 29fec5da8d user: larrybr)

If the documentation of sqlite3_finalize holds the truth ...

It does. The phrase "can result in undefined behavior" includes the possibility of behavior not recognized as grievous. A better phrasing might be "results in undefined behavior" (which includes not seg-faulting), but that invites the same perplexity you have shared.

then the documentation of sqlite3_step deserves an update to avoid confusion.

I am not seeing it that way yet. What specific part of the doc you quoted for the SQLITE_MISUSE return do you believe to be false or confusing? If that return is seen, it means what is claimed. That logical (if-then) relation does not imply its converse, (which would be "If this routine is called inappropriately, then SQLITE_MISUSE will be returned.") Among the possible outcomes of an inappropriate call is a seg-fault, as is documented explicitly and is implicitly included in "undefined behavior".

At present, I am disinclined to further elaborate that documentation merely to make explicit such a result of elementary logic. Doing so would be in the same category as adding, to every positive assertion, something like: "This does not mean P, Q, R ... (without logical end)."

13:36 Reply: sqlite3_step after sqlite3_finalize: what is the expected behavior? (artifact: 2b7a62eb8d user: larrybr)

If the documentation of sqlite3_finalize holds the truth ...

It does. The phrase "can result in undefined behavior" includes the possibility of behavior not recognized as grievous. A better phrasing might be "results in undefined behavior" (which includes not seg-faulting), but that invites the same perplexity you have shared.

then the documentation of sqlite3_step deserves an update to avoid confusion.

I am not seeing it that way yet. What specific part of the doc you quoted for the SQLITE_MISUSE return do you believe to be false or confusing? If that return is seen, it means what is claimed. That logical (if-then) relation does not imply its converse, (which would be "If this routine is called inappropriately, then SQLITE_MISUSE will be returned.") Among the possible outcomes of an inappropriate call is a seg-fault, as is documented explicitly and is implicitly included in "undefined behavior".

At present, I am disinclined to further elaborate that documentation merely to make explicit such a result of elementary logic). Doing so would be in the same category as adding, to every positive assertion, something like: "This does not mean P, Q, R ... (without logical end)."

2021-09-17
20:05 Reply: create taable with syntax error works ? (artifact: 30e7ea01ba user: larrybr)

To approach this another way:

The syntax for type-name permits this CREATE TABLE statement: CREATE TABLE MyStory ( Firstly I came up with a plot, subsequently I fleshed it out creating a draft, whereupon I cleaned it up for publication );

Your story better resembles the SQL accepted by some other DBMS without quite being legal input to another DBMS, but that is not enough to make SQLite choke on it.

19:54 Reply: create taable with syntax error works ? (artifact: 30a29e84dc user: larrybr)

You still have a strangely spelled affinity for the 3rd and final column specification. With your change, it meets criterion 2.

I did not say the affinity was your problem. Your problema is that, because of your strange spelling, you expect an error but SQLite does not see one.


a. This might be considered SQLite's problem, but it is a long-standing one. You may be interested in a soon-to-be-released SQLite feature, details of which can be seen here and in this forum in threads with "strict" (or casing equivalents) in their title.

18:54 Reply: create taable with syntax error works ? (artifact: 889e868b46 user: larrybr)

See section "3.1. Determination Of Column Affinity" in Datatypes In SQLite Version 3. Your 3rd (and last) column has the strange type, "String ProjectStartDate DATE", which you can see (per criterion 5) resolves to NUMERIC.

2021-09-16
20:07 Reply: missing sqlite.interop.dll (artifact: f887c4df95 user: larrybr)

I'm extrapolating from sparse input here, so more detail would help if this surmise is wrong: I suspect that you have attempted to use a SQLite.Interop.dll that was built for the Intel/AMD x86/x64 CPUs rather than for Arm CPUs. (And the DLL is not really "missing" as your thread title suggests; it is not loadable and the one that would be loadable is not yet present.)

I do not know where you will find the Arm-targeted DLL already built. You may have to build it from source.

15:22 Reply: segmentation fault when closing a database from within a transaction (artifact: 4ff6163677 user: larrybr)

Thanks for reporting this. Dan Kennedy's fix is at https://www.sqlite.org/src/info/e54a33ce56432b23 .

15:13 Reply: Javascript enforcement (artifact: 5c22311b21 user: larrybr)

I see nothing in that HTML which warrants suggestions of odor, malice, or snooping.

How did you get to that page?

2021-09-15
11:38 Reply: Writing a SQLite db as separate files (artifact: 1e0637b95f user: larrybr)

You might consider using rsync.

2021-09-14
16:00 Reply: DELETE FROM … RETURNING (artifact: a372f30117 user: larrybr)

... whether an intelligent programmer would consider this a bug ...

Given that the behavior is clearly documented, it's not a bug.

A perhaps more interesting question is: Should delete ordering be supported?

15:56 Reply: Select query returning: no such table error (artifact: 7d048f8db3 user: larrybr)

Either the hardware substrate is wonky, something else is also accessing the database, or some other software running in the same process is corrupting the data used by SQLite.

More details would help narrow these broad categories.

08:07 Reply: INTEGRITY OS support (artifact: c70c5fe4c0 user: larrybr)

Looking at the code, it appears that compiling with preprocessor symbol HAVE_FCHOWN not defined would solve your immediate problem. Whether that leads to other problems would be for your experiment to determine, I think.

2021-09-13
23:15 Reply: .read command breaks on reading from named pipes (artifact: 07329d4294 user: larrybr)

This modification should cure that woe. Please let me know if that is not the case.

15:01 Reply: integer overflow in pager.c (artifact: 467aa2cce8 user: larrybr)

My point went only to Gunter's assertion about multiplication details in C, not the OP's bug report. As can be seen in Richard's fix, he thinks a fix is necessary. I had gotten only to determining the limits of each operand's valuea before I saw his determination that an overflow needed to be avoided.


a. Whether an overflow was possible or not depends on the actual maximum operand values rather than just their types. So a deeper code analysis was required than what was evident in the OP's statements.

13:31 Reply: integer overflow in pager.c (artifact: 3058e1be26 user: larrybr)

Both statements multiply two 32 bit integers yielding a 64 bit result.

That would be a reasonable result, (and conforms to what many/most hardware multipliers do), but does not conform to C rules. In C, this: i64 sz = (pPager->pageSize+4)*pRel->iSubRec; , where the pageSize and iSubRec members are both 32-bit objects, means: Multiply these 32-bit integers to produce a 32-bit integer, then promote that integer to 64 bits (by sign bit extension or 0-fill according to signedness of the operands) and transfer into the 64-bit assignee.

This is counter-intuitive, but it avoids a language design issue where type must flow toward leaves of expression trees.

More ↓