I asked this question on Stackoverflow with not much success, and a suggestion
to ask it on the list. So here I am. I have two tables, t1(id, t1Id, … other
cols …, fullText) and a FTS5 virtual table vt1(t1Id, fullText)
```
sqlite> EXPLAIN QUERY PLAN
...> SELECT Count(*) as num FROM t1 WHERE
On 7/3/63 14:58, P Kishor wrote:
I asked this question on Stackoverflow with not much success, and a suggestion
to ask it on the list. So here I am. I have two tables, t1(id, t1Id, … other
cols …, fullText) and a FTS5 virtual table vt1(t1Id, fullText)
```
sqlite> EXPLAIN QUERY PLAN
...>
You mean like take a "boo" at the defined triggers?
select name, tbl_name, sql from sqlite_master where type='trigger';
would pretty much make clear that the defined trigger is not what you thought
it was ...
create table x(x);
create trigger after insert on x begin select 1; end;
select
Would it be possible to create an SQL verification program, which just like
'sqlite3_analyzer' and 'sqldiff' could be run separately?
It could *warn* about apparently incompletely defined triggers and other
possible pitfalls.
Then developers could use it before installing the next version of
I just want to point something out that might help the original poster.
On Saturday, March 7, 2020, 7:00:21 AM EST,
sqlite-users-requ...@mailinglists.sqlite.org
wrote: >
> 1. NULL is NULL = Yes, True,
> 2. NULL is FALSE = Nope, False.
> 3. NULL is TRUE = Nope, False.
> 4. NULL is
On 7 Mar 2020, at 4:49pm, John G wrote:
> Would it be possible to create an SQL verification program, which just like
> 'sqlite3_analyzer' and 'sqldiff' could be run separately?
> It could *warn* about apparently incompletely defined triggers and other
> possible pitfalls.
The shell tool has
6 matches
Mail list logo
