On 11 Feb 2020, at 4:10am, Peng Yu wrote:
> It seems that sqlite3 databases are not searchable by Spotlight on Mac OS X.
> Is there a way to make them searchable? Thanks.
A long time ago I wrote a SQLite indexer for … I think it was Sherlock back
then. It went through all text fields
Hi,
It seems that sqlite3 databases are not searchable by Spotlight on Mac
OS X. Is there a way to make them searchable? Thanks.
--
Regards,
Peng
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
On 10 Feb 2020, at 10:41pm, Wolfgang Enzinger wrote:
> Am Mon, 10 Feb 2020 01:42:14 + schrieb Simon Slavin:
>
>> On 10 Feb 2020, at 1:25am, no...@null.net wrote:
>>
>> create two VIEWs, [...]. Index both VIEWs on (id, date),
>
> I don't think that creating an index on a view actually
On Monday, 10 February, 2020 14:36, Simon Slavin wrote:
>Does this problem affect unnumbered indexes too ? In other words if I
>have
>(?,?,?,?,?)
>and bind to the fifth one using the index do I have the same problems as
>having
>(?1,?2,?3,?4,?5)
>and bind to the fifth one using its number
Am Mon, 10 Feb 2020 01:42:14 + schrieb Simon Slavin:
> On 10 Feb 2020, at 1:25am, no...@null.net wrote:
>
> create two VIEWs, [...]. Index both VIEWs on (id, date),
I don't think that creating an index on a view actually works, does it?
Wolfgang
Does this problem affect unnumbered indexes too ? In other words if I have
(?,?,?,?,?)
and bind to the fifth one using the index do I have the same problems as having
(?1,?2,?3,?4,?5)
and bind to the fifth one using its number ?
___
sqlite-users
On 2/10/20, Digital Dog wrote:
> Maybe they should be treated as a
> dictionary/hashtable/linked list or similar?
>
Parameter look-ups are on the critical path. How much performance are
you willing to give up in order to have parameters with larger
numbers?
--
D. Richard Hipp
d...@sqlite.org
On Mon, Feb 10, 2020 at 8:27 PM Richard Hipp wrote:
> On 2/10/20, Digital Dog wrote:
> >
> > Nobody bothered to actually show the downside of increasing this value to
> > e.g. 10 thousands but everybody immediately proceeded to grumble.
> > What is the justifiable rationale to not change the
On 2/10/20, Digital Dog wrote:
>
> Nobody bothered to actually show the downside of increasing this value to
> e.g. 10 thousands but everybody immediately proceeded to grumble.
> What is the justifiable rationale to not change the default?
The maximum number of variables used to be unlimited
The page https://sqlite.org/src/doc/begin-concurrent/doc/begin_concurrent.md
contains raw html:
INSERT INTO t1(b) VALUES(blob-value>);
--
Mark Lawrence
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
Huh so the typical ranting for a valid use case has happened.
> Another alternative is to construct the command as a string.
begging for SQL injection. Thanks, no.
> all the suggestions and examples with temporary tables
and that's what you call easy for the programmer?
Nobody bothered to
Sorry, I made a typo. The windows should be ORDER BY ROWID, not ORDER BY
ID.
Jen
On Mon, Feb 10, 2020 at 09:19:59AM -0700, Jen Pollock wrote:
> I think the following works:
>
> SELECT s.ID 'ID', s.Date Date, Systolic, Diastolic
> FROM
> (SELECT ID, ENTRY_DATE Date, NUMERIC_VALUE Systolic,
I think the following works:
SELECT s.ID 'ID', s.Date Date, Systolic, Diastolic
FROM
(SELECT ID, ENTRY_DATE Date, NUMERIC_VALUE Systolic, row_number() OVER id_date
r
FROM pressure
WHERE TERM = 'Systolic'
WINDOW id_date AS (PARTITION BY ID, ENTRY_DATE ORDER BY ID)
) s
JOIN
(SELECT ID,
On 2/9/20 11:44 PM, Rowan Worth wrote:
On Mon, 10 Feb 2020 at 11:12, Richard Damon
wrote:
On 2/9/20 7:24 PM, Bart Smissaert wrote:
ID ENTRY_DATE TERM NUMERIC_VALUE ROWID
1308 15/Mar/2013 Systolic 127 701559
1308 15/Mar/2013
I fully agree with you, but I sofar I have no control over this data, I
have it like I showed.
As far as I can see there always will be a secondary value, but as you say
I can't be sure.
All this has to do with changing our clinical coding system from Read codes
to Snomed.
In the old setup there
15 matches
Mail list logo