Re: [sqlite] SQLite iOS timestamp type mapping settings must be set to float to get correct data

On Nov 20, 2018, at 12:41 PM, Jens Alfke wrote: > On Nov 20, 2018, at 11:44 AM, Bill Hashman > wrote: > >> The timestamp from iOS systems is not compliant with ISO 8601/Unix or other >> common timestamps. It appears apple has their start date offset 31 years. > > Yes, the ‘epoch’ in

Re: [sqlite] ___fixunsdfdi

On Jun 18, 2018, at 3:21 AM, x wrote: > I’m using c++ builder 10.2 Tokyo on windows 10 pro. > In a console app I’m getting this error message > > [ilink32 Error] Error: Unresolved external '___fixunsdfdi' referenced from > C:\...\PROJECTS\WIN32\DEBUG\SQLITE3.OBJ > > I can’t find any mention

Re: [sqlite] Cannot initialize statically linked extension

On Dec 4, 2017, at 3:42 PM, Keith Medcalf wrote: > On Monday, 4 December, 2017 15:44, Jens Alfke wrote: > >>> If one object is using, for example, the multithreaded runtime and >>> the others are using the single threaded runtime (for example), and >>>

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 27, 2017, at 10:00 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > On Wednesday, 27 September, 2017 10:39, Guy Harris <g...@alum.mit.edu> wrote: > >> On Sep 27, 2017, at 6:58 AM, Keith Medcalf <kmedc...@dessus.com> wrote: > >>> Well, the termi

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 27, 2017, at 6:58 AM, Keith Medcalf wrote: > Well, the terminology is correct. These *ARE* I/O Errors. The system > attempted I/O. It failed. Hence the term I/O Error. Just don't call it a "disk I/O error". > It is irrelevant whether the error was caused

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 3:11 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 26 Sep 2017, at 10:53pm, Guy Harris <g...@alum.mit.edu> wrote: >> >> I *would* suggests an additional API to get a *separate* extended error >> code, so that if, for example, a write()

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 2:22 PM, Jens Alfke <j...@mooseyard.com> wrote: >> On Sep 26, 2017, at 1:57 PM, Guy Harris <g...@alum.mit.edu> wrote: >> >> Which means "for stuff that would be shown to the user, for the user to >> read, either localize your erro

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 2:08 PM, Scott Robison wrote: > There are physical errors and there are logical errors. If an error is > generated from write, it's not unreasonable to classify it as an > "output error". From read as an "input error". "Output error", yes, although

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 2:16 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 26 Sep 2017, at 9:57pm, Guy Harris <g...@alum.mit.edu> wrote: > >> On Sep 26, 2017, at 1:37 PM, Jens Alfke <j...@mooseyard.com> wrote: >> >>>> On Sep 26, 2017,

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 1:43 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 26 Sep 2017, at 9:17pm, Guy Harris <g...@alum.mit.edu> wrote: > >> The *number* might annoy the support staff; right off the top of your head, >> what's the error number for "file s

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 1:37 PM, Jens Alfke <j...@mooseyard.com> wrote: >> On Sep 26, 2017, at 1:17 PM, Guy Harris <g...@alum.mit.edu> wrote: >> >> A user wouldn't know what to do with "you've exceeded your stored data >> quota”? > > A Turkish o

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 1:05 PM, Simon Slavin <slav...@bigfraud.org> wrote: > On 26 Sep 2017, at 8:47pm, Guy Harris <g...@alum.mit.edu> wrote: > >> On Sep 26, 2017, at 8:22 AM, Jens Alfke <j...@mooseyard.com> wrote: >> >>> The basic error code is SQLI

Re: [sqlite] bug: failure to write journal reported as "disk I/O error"

On Sep 26, 2017, at 8:22 AM, Jens Alfke wrote: > The basic error code is SQLITE_IOERR, which just means "Some kind of disk I/O > error occurred” according to the comment. Which is true in this case; an I/O > operation returned an error. But the *disk* didn't - the

[sqlite] Lemon-generated parser gives an assertion failure

If you use the version of lemon.c and lempar.c in the Fossil repository for SQLite as of 2017-04-16 20:54:23 UTC, take the following Lemon parser, compile it, and run it, it fails with Assertion failed: (yyruleno!=116), function yy_reduce, file mate_grammar.c, line 2165. (It's a

Re: [sqlite] Get rid of old-style function declarations/definitions in lemon.c

On Apr 14, 2017, at 3:59 AM, Richard Damon wrote: > In C (as opposed to C++), it is the only way to provide a real prototype for > such a function. The empty parameter list means with an unspecified parameter > list in C. Exactly. Perhaps some future C standard will

Re: [sqlite] Get rid of old-style function declarations/definitions in lemon.c

On Apr 13, 2017, at 2:36 AM, Dominique Devienne <ddevie...@gmail.com> wrote: > On Thu, Apr 13, 2017 at 6:18 AM, Guy Harris <g...@alum.mit.edu> wrote: > >> Here's a patch, against the current Fossil repository, including some >> changes we've made to lemon.c in W

[sqlite] Get rid of old-style function declarations/definitions in lemon.c

Here's a patch, against the current Fossil repository, including some changes we've made to lemon.c in Wireshark, that gets rid of old-style K function definitions/declarations, and also removes trailing white space from some lines (the Wireshark pre-commit hook complains about them):

Re: [sqlite] Bug report + fix: SQLite 3.11+ broken on EBCDIC systems

On Dec 11, 2016, at 4:57 PM, Richard Hipp wrote: > I agree with most of your changes. But I wonder about moving the > QUOTE2 (the '[' character) value from code 0xba over to 0xad. > According to EBCDIC chart at https://en.wikipedia.org/wiki/EBCDIC the > '[' character should be