A few builds ago I got a similar message. ?I don't recall whether I actively
tried to use threads or got blindsided by change. ?The short story is that
linking in libpthread caused the build to succeed. ?The longer story is that
threads were unreliable in my environment (Windows/cygwin), caused
On Wed, 27 Jan 2016 14:38:41 -0500
Richard Hipp wrote:
>
> See https://www.sqlite.org/nulls.html
>
The most important part to me, is this one:
> The fact that NULLs are distinct for UNIQUE columns but are indistinct for
> SELECT DISTINCT and UNION continues to be puzzling. It seems that
On Wed, 27 Jan 2016 14:17:49 -0500
Igor Tandetnik wrote:
> On 1/27/2016 2:10 PM, Yannick Duch?ne wrote:
> > `UNIQUE` constraint allows multiple NULL: is this expected?
>
> http://www.sqlite.org/lang_createtable.html
> "For the purposes of UNIQUE constraints, NULL values are considered
>
I like SQLite because it's simple and also because I believe it sticks to the
standard, therefore I get the habit to use SQLite to learn standard SQL.
Today, I came to a page from the documentation, about a construct which is
supported for compatibility with MySQL and elsewhere I learned (if
Hi people out there,
I initially subscribed for another question (which I will post later), when I
came to something which surprised me.
Given this:
CREATE TABLE test (value TEXT UNIQUE)
On this:
INSERT INTO test (value) VALUES('A');
INSERT INTO test (value) VALUES('A')
? the
On 27 Jan 2016, at 7:22pm, Yannick Duch?ne wrote:
> By the way, another related question: the only reference for standard SQL I
> have (which I have not read yet) is for SQL1992. Does this version of the
> standard covers most of commonly used SQL or does it lack a lot of things? Or
>
On 1/27/16, Yannick Duch?ne wrote:
> On Wed, 27 Jan 2016 14:17:49 -0500
> Igor Tandetnik wrote:
>
>> On 1/27/2016 2:10 PM, Yannick Duch?ne wrote:
>> > `UNIQUE` constraint allows multiple NULL: is this expected?
>>
>> http://www.sqlite.org/lang_createtable.html
>> "For the purposes of UNIQUE
On 27 Jan 2016, at 2:28pm, Jay Kreibich wrote:
> Generally speaking, there is no standard way to recover from a corrupt
> database. The best policy is not to corrupt it in the first place.
True, but if you have to corrupt it in the first place,
1) Try using the shell tool to .dump and then
On Wed, 27 Jan 2016 08:51:16 +
Bernard McNeill wrote:
> Using the standard defaults (which avoid WAL), is there any
> possibility whatsoever of that last SQL transaction being lost?
I have an unusual answer: Yes, and it doesn't matter.
Let's suppose, as you did, that the application got
On 1/27/2016 2:10 PM, Yannick Duch?ne wrote:
> `UNIQUE` constraint allows multiple NULL: is this expected?
http://www.sqlite.org/lang_createtable.html
"For the purposes of UNIQUE constraints, NULL values are considered
distinct from all other values, including other NULLs."
I'm reasonably, but
On 21 January 2016 at 11:16, Richard Hipp wrote:
> The change that is causing your problem was put in at the suggestion
> of Hanno B?ck on the sqlite-dev mailing list. Hanno said he was going
> to try to contact you off-list in order to figure out how to reproduce
> the issue you are seeing and
On 25 January 2016 at 18:26, Meinlschmidt Stefan <
Stefan.Meinlschmidt at esolutions.de> wrote:
> > In your case it sounds like a controlled shutdown - is there a reason you
> > don't do a full disk sync before that?
>
> Yes, it is a controlled shutdown, so in my case the /* post-commit logic
>
On 27 Jan 2016, at 8:51am, Bernard McNeill wrote:
> Situation: Under Linux/Debian, Sqlite opens an entirely valid DB, and runs
> an entirely valid SQL transaction against that database.
> Following a Commit, the application gets back a 'Commit Successful' code.
> (Ignore any issues of disks
Just to be clear
Situation: Under Linux/Debian, Sqlite opens an entirely valid DB, and runs
an entirely valid SQL transaction against that database.
Following a Commit, the application gets back a 'Commit Successful' code.
(Ignore any issues of disks returning hardware 'write done' flags
The backup API is not designed to recover corrupted databases.
Generally speaking, there is no standard way to recover from a corrupt
database. The best policy is not to corrupt it in the first place. In
practice, if you follow the rules, it is very very hard to corrupt a database.
Just be
On Wed, Jan 27, 2016 at 6:28 AM, Jay Kreibich wrote:
>
> The backup API is not designed to recover corrupted databases.
>
> Generally speaking, there is no standard way to recover from a corrupt
> database. The best policy is not to corrupt it in the first place. In
> practice, if you follow
I was wondering if the backup api (sqlite3_backup_init, et al. ) will
help to recover a corrupt DB? All the other mechanisms are an export
and re-import into a new DB...
The database exists in a encrypted database that it's really difficult
to get the keys outside of the program and I don't look
17 matches
Mail list logo
