On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
> On 2/1/20, Thomas Kurz wrote:
> > Does this mean there will be no possibility to prevent inserting a string
> > into an integer column anymore?
> >
> > create table x (x integer check (typeof(x) == 'integer'));
> > insert into x values
INSTR() ignores NOCASE on columns
---
example:
SELECT * FROM table WHERE INSTR(column, ' castle ') > 0
returns datasets with 'castle' only, without 'Castle', even if the
column is set to NOCASE
---
LIKE doesn't have this problem, works well
SELECT
Differing by 1. I noticed this today for 1 table only but not always -
sometimes they were equal. I’ve been unable to reproduce it after a vacuum.
Does this indicate a corrupt db or is it a case of it can happen for some
reason I’ve missed?
___
They shouldn't be different, no. Do you have a copy of the weird version of the
database still, or have a copy of the explain text and the sqlite_master
contents? Was there another index or table whose root page is what was listed
in the explain output? For example, were you expecting it to use
Consider this:
.print Issue with generated columns
create table a(n,s as (n+1));
insert into a values(1),(2),(3);
select * from a;
create table b as select * from a;
.print table b converted the generated column into a regular column
select * from b;
delete from a;
insert into a select * from
Consider this:
.print Issue with generated columns
create table a(n,s as (n+1));
insert into a values(1),(2),(3);
select * from a;
create table b as select * from a;
.print table b converted the generated column into a regular column
select * from b;
delete from a;
insert into a select * from
There's usage of sqlite3_set_authorizer within shell.c that's not wrapped with
the test for if SQLITE_OMIT_AUTHORIZATION is defined that prevents compilation
of the shell.c if the configuration includes this define.
I've provided a diff with a fix below:
$ git diff
diff --git a/shell.c
On 2/3/20, Dominique Devienne wrote:
> On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
>> On 2/1/20, Thomas Kurz wrote:
>> >
>> > create table x (x integer check (typeof(x) == 'integer'));
>> > insert into x values ('1');
>> >
>> > --> will pass in future versions???
>>
>> I think that is
Hi David,
The two queries were as follows
explain select vCol,* from Race,Meta.vCols;
and
select * from meta.sqlite_master where type='table';
Sorry, I don’t have a copy of the unvacuumed db.
From: sqlite-users on behalf of
David Raymond
Sent: Monday,
On Mon, 3 Feb 2020 10:45:50 +0100
Dominique Devienne wrote:
> On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
> > On 2/1/20, Thomas Kurz wrote:
> > > Does this mean there will be no possibility to prevent inserting
> > > a string into an integer column anymore?
> > >
> > > create table
On Mon, Feb 3, 2020 at 5:35 PM Richard Hipp wrote:
> On 2/3/20, Dominique Devienne wrote:
> > On Sun, Feb 2, 2020 at 12:50 AM Richard Hipp wrote:
>
> This is the SQL:
>
> CREATE TABLE t1(x INT CHECK(typeof(x)=='integer'));
> INSERT INTO t1(x) VALUES('123');
>
> You say that you want to
On Sun, 2 Feb 2020 10:05:11 +0100
Markus Winand wrote:
> When you say ?many standards? do you mean the different releases
> those standards have?
Yes.
> IMHO, there is only one SQL standard, namely ISO/IEC 9075. The
> current and technically only valid version is that of 2016 (even
> though
Thank you to everyone who has provided help in resolving this problem for me.
Regards,
Rob
Rob Golding
Geospatial Specialist (Geospatial Analytics Team)
Asset Information Services: inspiring and enabling through the power of data
Willen, The Quadrant: MK, Elder Gate, Milton Keynes, MK9
> You say that you want to prevent the use of the string literal '123'
> for inserting into the integer field x. That will no longer be
> possible in SQLite beginning with 3.32.0 (assuming the change
> currently on trunk goes through.)
> But, why do you want to do that?
You are right. I
Hello there,
I was running some queries using FTS5 in my database and I generally
sanitize the input by removing non-ascii characters, except for all the
unicode chars above 128 or so. That way I get rid of stuff like quotes,
double quotes, periods, etc.
However my queries where choking on some
On 3 Feb 2020, at 9:30pm, David Guillen Fandos wrote:
> However my queries where choking on some input that contained the U+2018 and
> U+2019 characters. It seems like these chars are being treated like a regular
> quote character
At least one version of SQL respects those characters for
16 matches
Mail list logo
