There are pragmas to toggle SQLite to use case sensitive LIKE statements.
I can't think of what it is right now (Busy with something else) but the
doc does have the required statement.
I know squat about PGSql, but in MySQL and Maria, by default, LIKE is case
insensitive. It might be an option be
In SqLite, LIKE works backwards. It's not case-sensitive, although it
should be.
It's far too late to change this now, it would break all manner of existing
code.
But, in more advanced engines (like PostgreSQL), LIKE is a case-sensitive
match, and ILIKE is a case insensitive match.
I suggest tha
On 08.01.2017 12:54, Clemens Ladisch wrote:
Kirill Müller wrote:
... there's no portable support for 64-bit integers.
That's what SQLite looks at SQLITE_INT64_TYPE.
The patch introduces SQLITE_UINT64_TYPE.
I'm working around this issue by using a struct of size 8
A struct of size 8 does no
On 08.01.2017 21:24, Richard Hipp wrote:
On 1/7/17, Kirill Müller wrote:
I'm in a situation [1] where I compile RSQLite as part of a C++ project
that still uses the C++98 standard.
Can you instead compile SQLite as a library (libsqlite3.a) using gcc
or clang, then link the compiled *.a file in
On 08.01.2017 17:38, Clemens Ladisch wrote:
Kirill Müller wrote:
... there's no portable support for 64-bit integers.
I'm working around this issue by using a struct of size 8
I'm open to alternatives.
What's wrong with SQLITE_INT64_TYPE?
(Even older C++ compilers should have the C .)
Thanks.
On 1/7/17, Kirill Müller wrote:
>
> I'm in a situation [1] where I compile RSQLite as part of a C++ project
> that still uses the C++98 standard.
Can you instead compile SQLite as a library (libsqlite3.a) using gcc
or clang, then link the compiled *.a file into your project, so that
your C++98 co
as an alternative you can use the same ID - nessecitating prefiixing the
primary id with the table name... but then natural join can work.
(Although common words like 'name' should also be table-name prefixed).
Having a 'id' as the primary key disallows the using() shorthand also.
If all column
On 8 Jan 2017, at 12:46pm, Gan Uesli Starling wrote:
> But it seems theres no way to make that a single, all-in-one-go kind of query.
Are you aware of SELECT … JOIN … ?
SELECT state.this,country.that FROM state
JOIN country ON country.name = state.country
WHERE state.name = "Wa
On Sun, Jan 8, 2017 at 6:23 AM, Kirill Müller wrote:
> On 08.01.2017 14:20, Clemens Ladisch wrote:
>> Kirill Müller wrote:
>>> On 08.01.2017 12:54, Clemens Ladisch wrote:
Kirill Müller wrote:
> ... there's no portable support for 64-bit integers.
> I'm working around this issue by usi
Kirill Müller wrote:
> ... there's no portable support for 64-bit integers.
> I'm working around this issue by using a struct of size 8
>
> I'm open to alternatives.
What's wrong with SQLITE_INT64_TYPE?
(Even older C++ compilers should have the C .)
Regards,
Clemens
_
On 08.01.2017 14:20, Clemens Ladisch wrote:
Kirill Müller wrote:
On 08.01.2017 12:54, Clemens Ladisch wrote:
Kirill Müller wrote:
... there's no portable support for 64-bit integers.
I'm working around this issue by using a struct of size 8
A struct of size 8 does not behave the same as an in
Kirill Müller wrote:
> On 08.01.2017 12:54, Clemens Ladisch wrote:
>> Kirill Müller wrote:
>>> ... there's no portable support for 64-bit integers.
>>> I'm working around this issue by using a struct of size 8
>>
>> A struct of size 8 does not behave the same as an integer type.
>>
> For compiling
On Sunday, 8 January, 2017 05:05, Ken Wagner wrote:
> Keith,
>
> Ahh, better to be specific and avoid simplistic assumptions.
>
> For foreign keys which is better: 'trackerartist' or 'artistid' in the
> track file? Does it matter? Is it personal preference?
It is a matter of personal preferen
On 08.01.2017 12:54, Clemens Ladisch wrote:
Kirill Müller wrote:
... there's no portable support for 64-bit integers.
That's what SQLite looks at SQLITE_INT64_TYPE.
The patch introduces SQLITE_UINT64_TYPE.
I'm working around this issue by using a struct of size 8
A struct of size 8 does no
Okay, this trigger what works. Not really an answer, since there's no
simplification achieved. Still thought I'd post it though, as a
conclusion-of-sorts nonetheless. It's neither clever nor elegant, but it
does work. Hammer and tongs, is what it is. There's no decision tree for
choosing when
Keith,
Ahh, better to be specific and avoid simplistic assumptions.
For foreign keys which is better: 'trackerartist' or 'artistid' in the
track file? Does it matter? Is it personal preference?
Ken
On 01/08/2017 05:46 AM, Keith Medcalf wrote:
... join ... using (column) has nothing whateve
Kirill Müller wrote:
> ... there's no portable support for 64-bit integers.
That's what SQLite looks at SQLITE_INT64_TYPE.
> I'm working around this issue by using a struct of size 8
A struct of size 8 does not behave the same as an integer type.
> Currently I'm applying the attached patch
Thi
... join ... using (column) has nothing whatever to do with foreign keys.
"FROM a JOIN b USING (c) is "syntactic sugar" (meaning that it is sweetening
and full of calories, but has no nutritional value) for the expression "FROM a,
b WHERE a.c = b.c"
This is so, for example, if you use really
Thanks, Kees,
The message is helpful as a warning.
select artistname, trackname from artist inner join track on
trackartist = artistid; works just fine.
But isn't the efficiency of 'using (artistid)' more desirable?
Is the use of a 'trackerartist' as the foreign key used because it is
more i
On Sun, 8 Jan 2017 04:21:16 -0600, Ken Wagner
wrote:
>Hello SQLusers,
>
> The error below occurs even though the
>
> CREATE TABLE track(
>
> trackid INTEGER,
> trackname TEXT,
> trackartist INTEGER,
> *FOREIGN KEY(trackartist) REFERENCES artist(artistid)*
> );
>
> statement at https
Hello SQLusers,
The error below occurs even though the
CREATE TABLE track(
trackid INTEGER,
trackname TEXT,
trackartist INTEGER,
*FOREIGN KEY(trackartist) REFERENCES artist(artistid)*
);
statement at https://sqlite.org/foreignkeys.html was observed.
It appears that 'trackerartis
21 matches
Mail list logo
