Robert M. Münch wrote:
> Is this behaviour standard or a SQLite variant?
Autoincrementing is an SQLite variant.
Default values are standard SQL.
It should be noted that standard SQL (above Entry SQL level) allows
DEFAULT in row value constructors.
Regards,
Clemens
__
On 28 Jun 2017, at 14:51, Simon Slavin wrote:
> 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 overridden with a DEFAULT clause).
I had exactly the same understanding. BTW: Is thi
On 28 Jun 2017, at 9:49, Maks Verver wrote:
> 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 d
On 27 Jun 2017, at 22:24, David Raymond wrote:
> If you have to provide 4 values then the way you can use null to do that is
> to add in a trigger to set the default, since NULL _is_ a value and _is_
> legal for that field.
Ha, that's a very good idea. I didn't have triggers in the radar. Great
On 27 Jun 2017, at 22:11, David Raymond wrote:
> Single quotes should be used for strings, so DEFAULT '-'
I thought it doesn't matter if I use " or ' for strings. What's the difference?
> So there is no method to do something like...
>
> INSERT INTO test VALUES ('field a', DEFAULT, 'field c', '
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? What is it really do
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 ex
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 [mailto
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 indeed be utf-8. Not always, but a memor
> 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
> confusion later.
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 that NULLs
were converted to the default v
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 p
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. Sorry about
> that.
>
> Simon.
>
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 specific initialization
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 by sqlite3_close() to
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 ove
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 SQLITE_OK
? This doesn’t defi
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 a cosmic ray.
>
> Conv
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 is usually NULL but
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 screw up ...
> and remain undetectable.
Nowadays we use packet checksums and
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 SQLITE_MISUSE error co
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:
http://s
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 sqlite_close(handle
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 you are leaking prepare
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 ins
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 you the whole project be
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 to
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. Is this possible at all?
>
>
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 T
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 devel
30 matches
Mail list logo
