On 6/28/17, Jeremy Zeiber wrote:
>
> According to https://sqlite.org/datatype3.html section 4.2, if one
> operator in a comparison is TEXT and the other is INTEGER or no
> affinity, then the TEXT operator is converted to NUMERIC.
>
> Could someone explain the varying results?
I've experienced some weirdness with the results of a comparison
between values of different data types. I'm not sure if this is due
to type affinity, implicit conversion, or something else, but it
doesn't behave as I expect it to as indicated in the documentation.
Take the following query for
Dear all,
Please can any e-mail address that ends "@sentec.co.uk" be removed from the
mailing list as I am receiving a number of e-mails for ex-employees but there
is no way to unsubscribe on the e-mails.
Many thanks
With kind regards
Liz
-Original Message-
From: sqlite-users
On 28 Jun 2017 at 14:20, Rowan Worth wrote:
> On 27 June 2017 at 18:42, Eric Grange wrote:
>
>> So while in theory all the scenarios you describe are interesting, in
>> practice seeing an utf-8 BOM provides an extremely
>> high likeliness that a file will
> On Jun 28, 2017, at 4:15 PM, R Smith wrote:
>
> I did ponder whether it would be a nice "feature" to use the default if both
> a DEFAULT and a NOT NULL constraint existed on a column - but then again,
> that will go against strict design principles and can cause a lot of
On Jun 28, 2017 6:51 AM, "Simon Slavin" wrote:
On 28 Jun 2017, at 9:45am, Clemens Ladisch wrote:
> An explicit NULL works only for the autoincrement column, but not for
default values.
Really ? In that case I withdraw my previous answer. I thought
On 2017/06/28 4:33 PM, Simon Slavin wrote:
That’s two wrong things I’ve posted today. Must try harder. Sorry
about that.
I don't think that's a problem, we've seen wrong answers by near
everyone here - this is the beauty of a forum like this:
Once you are wrong, not only are there numerous
Its called learning. I've been shot down for this kind of err before. ;)
On Wed, Jun 28, 2017 at 10:33 AM, Simon Slavin wrote:
>
>
> On 28 Jun 2017, at 3:24pm, Dan Kennedy wrote:
>
> That’s two wrong things I’ve posted today. Must try harder.
On 28 Jun 2017, at 3:24pm, Dan Kennedy wrote:
> sqlite3_shutdown() will not close any open file descriptors or free any other
> leaked resources.
Ah. I read that it calls sqlite3_os_end() and the documentation says
"The sqlite3_os_init() routine does operating-system
On 06/28/2017 09:07 PM, Simon Slavin wrote:
On 28 Jun 2017, at 10:37am, Domonic Tom wrote:
After calling sqlite3_close(handle) I try then to use the 'remove' method in
C++ to delete my .db file. For some reason it just won't delete.
Are you testing the result returned
On 2017/06/28 2:51 PM, Simon Slavin wrote:
An explicit NULL works only for the autoincrement column, but not for default
values.
Really ? In that case I withdraw my previous answer. I thought that NULLs
were converted to the default value for a column (which is usually NULL but can
be
On 28 Jun 2017, at 10:37am, Domonic Tom wrote:
> After calling sqlite3_close(handle) I try then to use the 'remove' method in
> C++ to delete my .db file. For some reason it just won't delete.
Are you testing the result returned by sqlite3_close() to see if it’s
On 27 June 2017 at 18:42, Eric Grange wrote:
> So while in theory all the scenarios you describe are interesting, in
> practice seeing an utf-8 BOM provides an extremely
> high likeliness that a file will indeed be utf-8. Not always, but a memory
> chip could also be hit by
On 28 Jun 2017, at 9:45am, Clemens Ladisch wrote:
> An explicit NULL works only for the autoincrement column, but not for default
> values.
Really ? In that case I withdraw my previous answer. I thought that NULLs
were converted to the default value for a column (which
On 6/27/17, 4:02 PM, "sqlite-users on behalf of Keith Medcalf"
wrote:
> Nowadays we use 8 bits for data with no parity, no error correction, and no
> timing bits. Cuz when things screw up we want them to REALLY
On 6/28/17, Domonic Tom wrote:
> I was getting the error in some cases
> SQLITE_MISUSE .
An SQLITE_MISUSE error code means you have done something wrong that
could potentially cause a segfault or other application crash. You
need to fix that. It's important.
And, yes, an
Woops, I spoke too soon. Still can't delete the file.
I don't have any prepared statements, just simple sqlite3_open_v2 and
sqlite3_close statements. But, something along the lines of what you are
saying could be the issue.
I'm checking it out now.
--
View this message in context:
Thanks everyone for your help. I was getting the error in some cases
SQLITE_MISUSE . That's error code 21.
Throughout my functions I may have called sqlite_close too much and this has
caused some issues when going to delete the file. At this point removing all
the excess
On 6/28/17, Domonic Tom wrote:
>
> Would anyone know how to go about making sure that the database file is not
> busy and can be deleted. Is there a specific function for this.
>
Call sqlite3_finalize() on all prepared statements before calling
sqlite3_close(). Probably
It ain't SQLite keeping your file open.
Make sure the connection is closed properly (Typically calling the Close
command from your wrapper for SQLite) and then it should be free. Make
sure there is no other program with lingering connections to it, a
different project maybe, or a different
What is the return value of sqlite3_close?
RBS
On Wed, Jun 28, 2017 at 10:37 AM, Domonic Tom wrote:
> After calling sqlite3_close(handle) I try then to use the 'remove' method
> in C++ to delete my .db file. For some reason it just won't delete.
>
>
> It's hard to show
After calling sqlite3_close(handle) I try then to use the 'remove' method in
C++ to delete my .db file. For some reason it just won't delete.
It's hard to show you the whole project because it's large.
I believe this has something to do with sqlite3_close only de-allocating the
connection
Simon Slavin wrote:
> On 27 Jun 2017, at 8:13pm, Robert M. Münch
> wrote:
>> CREATE TABLE test(a, b DEFAULT "-", c, d)
>>
>> Now I would like to use
>>
>> INSERT VALUES(a,?,c,d)
>>
>> Where ? is something that the default value is used and not the provided
>> value.
I'm surprised nobody mentioned that you can specify the columns to be
inserted in the query:
INSERT INTO test(a, c, d) VALUES (1, 2 3);
(Note that `b` is missing it `a, c, d`. It will take the default value,
which will be NULL, unless a different default was specified explicitly in
the CREATE
We use an ODBC frontend which calls the user authentication functions.
The last release with working user authentication is 3.15.2.
Release 3.16.0 breaks user authentication.
There had been a lot of changes between those releases.
At the moment we do not have a patch.
Would be great if some
25 matches
Mail list logo