First off, my apologies for hijacking this thread.
But I've seen some strange things when messing with pragma writable_schema.
It appears all bets are off?
example: create a table of columns (x, y, z), and fill it with values.
then, modify sqlite_master to take out column z.
let's say later on dow
hy it
happened.
On Oct 17, 2016 5:21 PM, "Kees Nuyt" wrote:
> On Mon, 17 Oct 2016 15:40:44 -0500, Ben Newberg
> wrote:
>
> > But I've seen some strange things when messing with pragma
> writable_schema.
> > It appears all bets are off?
>
> Yes. that
select t0.key, "Issue Type", strftime('%Y-%m-%d %H:%M:%S', (Updated -
(julianday('1970-01-01') - julianday('1899-12-30'))) + 2440587.5) Updated
from JIRA_Stat_0_20170106124800 t0 inner join JIRA_Stat_1_20170106124800 t1
on t0.key = t1.key
where "Last Comment" is not null
order by assignee;
give
what i've done in the past is append a character to the value and make use
of "cast":
update desktops set indexNo = indexNo || '_';
update desktops set indexNo = cast(indexNo as integer) + 1;
then:
insert into desktops values (new row with index = 1);
from the docs, which i hope i'm not misreadi
Is that a homebrew version of 3.16.0?
SQLite version 3.16.0 2017-01-02 11:57:58
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .timer on
sqlite>
3.15.1 was released on 2016-11-04, but it works on that ve
The column can be unique as well, correct?
SQLite version 3.17.0 2017-02-13 16:02:40
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> pragma foreign_keys = 1;
sqlite> create table x (a integer primary key,
I've noticed with 3.18.0 that it's possible to make a database increase in
size after running pragma integrity_check (which returns "ok") and then
running vacuum.
Alternatively, vacuuming without running pragma integrity_check first keeps
the database the same size as before.
The page size on the
All,
Is it possible to have CTE's within triggers? The way I read the 'SQL As
Understood By SQLite', one can, but I could be misinterpreting it.
My DDL for my trigger is as follows:
CREATE TRIGGER t_populate_zweeks
AFTER UPDATE ON zSPs WHEN new.Procedure = 6 AND new.Flag = 1
BEGIN
DELETE FROM zW
, Simon Slavin wrote:
>
> On 11 Nov 2014, at 11:15pm, Ben Newberg wrote:
>
> > WITH RECURSIVE Weeks(wk) as (select 1 union all select wk + 1 from Weeks
> > limit 10)
> > INSERT INTO zWeeks (Week) select wk from Weeks;
>
> Just use 10 INSERT commands.
>
> I don
Thanks everyone. I will have the programming language do the work on this
one instead of going the trigger route.
On Nov 11, 2014 7:39 PM, "Richard Hipp" wrote:
> On Tue, Nov 11, 2014 at 8:22 PM, Igor Tandetnik
> wrote:
>
> On 11/11/2014 6:15 PM, Ben Newberg wrote:
>
+1 for the use of R for this task. I use the below if the file is in XLSX
format:
library(sqldf)
library(openxlsx)
df <- read.xlsx("mytable.xlsx", sheet=1, startRow=1, colNames=TRUE)
db <- dbConnect(SQLite(), "mydatabase.db")
dbWriteTable(db, "mytable", df)
On Sat, Aug 1, 2015 at 8:13 AM, Gabor G
Is there a good way to determine if a sql query is either attempting to
modify a database, or simply querying it?
In the past, I have used sqlite3_update_hook with good results, but in this
current project, I am looking for a way to determine the type of query even
before the prepared statement is
Excellent. This is exactly what I was looking for.
Thanks.
On Thu, Aug 6, 2015 at 11:50 AM, Stephan Beal wrote:
> On Thu, Aug 6, 2015 at 6:46 PM, Ben Newberg wrote:
>
> > Is there a good way to determine if a sql query is either attempting to
> > modify a database, or
13 matches
Mail list logo