Re: [sqlite] T-SQL to retrieve needed records

On Sat, 31 Aug 2013 22:04:54 +0200 Petite Abeille wrote: > > I changed the data (see below) because *meaning* of recordings.ends > > should be an "exclusive end", what's knows as a half-open interval. > > That makes the question of "does b follow a" one of equality. It is > > likely not the case

Re: [sqlite] to encrypt sqlite db

If Windows RT supports the "encrypted files and folders" option of the NTFS file system -- I could not find anything that said explicitly that it either was or was not supported, and I don't have a Windows RT device to test with -- that would definitely be the way to go. It would require only th

Re: [sqlite] T-SQL to retrieve needed records

On Aug 31, 2013, at 6:42 PM, James K. Lowden wrote: > I changed the data (see below) because *meaning* of recordings.ends > should be an "exclusive end", what's knows as a half-open interval. > That makes the question of "does b follow a" one of equality. It is > likely not the case that exactl

Re: [sqlite] to encrypt sqlite db

Wait, can you clarify what you mean by SEE here, and also which library you mean for BW? Thanks 2013/8/31 Etienne > > Those first few bytes are just as well known after they have been run > > through zlib or libbz2 or whatever compression library you are using. > Your > > encryption algorithm,

Re: [sqlite] to encrypt sqlite db

> > On Sat, 31 Aug 2013 17:17:23 +0200 > > Etienne wrote: > > > > > > On the other hand removing patterns definitely cannot hurt. > > > > > > Precisely. > > > > > > The very first bytes of SQLite files are, AFAIK, well known. > > > > That's what salt is for, no? > > > "nonce", "IV", "sa

Re: [sqlite] Question about index usage

> > CREATE TABLE DevProps > > ( > > CompID INTEGER NOT NULL, > > PropID INTEGER NOT NULL > > ); > > > > CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID, > > PropID); > ... > > SELECT CompID FROM DevProps WHERE PropID=33 > > > > it looks like it will be doing a table scan. Why is

Re: [sqlite] T-SQL to retrieve needed records

On Wed, 28 Aug 2013 14:58:35 -0700 (PDT) jdp12383 wrote: > Each record is a recording up to 3 min. I am trying to retrieve one > record per continuous recording. ... > CREATE TABLE recordings ( > [key] INTEGERPRIMARY KEY ASC AUTOINCREMENT, > filename VARCHAR(50),

Re: [sqlite] Question about index usage

On Fri, 30 Aug 2013 16:22:04 + Doug Nebeker wrote: > CREATE TABLE DevProps > ( > CompID INTEGER NOT NULL, > PropID INTEGER NOT NULL > ); > > CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID, > PropID); ... > SELECT CompID FROM DevProps WHERE PropID=33 > > it looks like it w

Re: [sqlite] to encrypt sqlite db

On Sat, Aug 31, 2013 at 1:10 PM, James K. Lowden wrote: > On Sat, 31 Aug 2013 17:17:23 +0200 > Etienne wrote: > > > > On the other hand removing patterns definitely cannot hurt. > > > > Precisely. > > > > The very first bytes of SQLite files are, AFAIK, well known. > > That's what salt is for, no

Re: [sqlite] to encrypt sqlite db

On Sat, 31 Aug 2013 17:17:23 +0200 Etienne wrote: > > On the other hand removing patterns definitely cannot hurt. > > Precisely. > > The very first bytes of SQLite files are, AFAIK, well known. That's what salt is for, no? --jkl ___ sqlite-users

Re: [sqlite] Why latest places.sqlite from firefox can't be opened by some older versions of sqlite

On Sat, Aug 31, 2013 at 10:14 PM, Richard Hipp wrote: > On Sat, Aug 31, 2013 at 2:03 PM, Max Vlasov wrote: > >> Hi, >> >> I noticed that opening places.sqlite of my installation of Firefox >> can't be made for example with sqlite 3.6.10, it says that file either >> encrypted or invalid > > Recent

Re: [sqlite] Why latest places.sqlite from firefox can't be opened by some older versions of sqlite

On Sat, Aug 31, 2013 at 2:03 PM, Max Vlasov wrote: > Hi, > > I noticed that opening places.sqlite of my installation of Firefox > can't be made for example with sqlite 3.6.10, it says that file either > encrypted or invalid (everything ok for example with 3.7.15.2 and sure > firefox itself, it wo

Re: [sqlite] Why latest places.sqlite from firefox can't be opened by some older versions of sqlite

On 31 Aug 2013, at 7:03pm, Max Vlasov wrote: > probably ff uses some > features making sqlite 3 format incompatible with 3.6.* versions According to format changes since 3.6.0: You could try opening the database with the sqlite command-line tool. Simon

Re: [sqlite] VACUUM silently fails, database size not changed

Unfortunately this does not help :-( It may have still something to do with WAL. Before I run the VACUUM the WAL file is quite small. After the VACUUM has completed, it is about 20 MB - about the same size as the properly compacted database would be. But when I run a pragma wal_checkpoint; the WA

[sqlite] Why latest places.sqlite from firefox can't be opened by some older versions of sqlite

Hi, I noticed that opening places.sqlite of my installation of Firefox can't be made for example with sqlite 3.6.10, it says that file either encrypted or invalid (everything ok for example with 3.7.15.2 and sure firefox itself, it works :)). This might be a failure of my particular installation

Re: [sqlite] Question about index usage

On 8/30/2013 12:22 PM, Doug Nebeker wrote: CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID, PropID); When I check the query plan for this statement: SELECT CompID FROM DevProps WHERE PropID=33 it looks like it will be doing a table scan. Why is that? Imagine that you have

Re: [sqlite] Question about index usage

Doug Nebeker wrote: > CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID, PropID); > > When I check the query plan for this statement: > > SELECT CompID FROM DevProps WHERE PropID=33 > > it looks like it will be doing a table scan. My version of SQLite uses a covering index, but is

Re: [sqlite] to encrypt sqlite db

> Those first few bytes are just as well known after they have been run > through zlib or libbz2 or whatever compression library you are using.  Your > encryption algorithm, whatever it is, needs to be resistant to a > known-plaintext attack. LZ is a sequential algorithm, while BW works with large

Re: [sqlite] to encrypt sqlite db

On Sat, Aug 31, 2013 at 11:17 AM, Etienne wrote: > > The very first bytes of SQLite files are, AFAIK, well known. > Those first few bytes are just as well known after they have been run through zlib or libbz2 or whatever compression library you are using. Your encryption algorithm, whatever it i

Re: [sqlite] to encrypt sqlite db

> That last sentence is quite weird, a good encryption system should > give a random-like sequence even with very low-entropy input. > > On the other hand removing patterns definitely cannot hurt. Precisely. The very first bytes of SQLite files are, AFAIK, well known. While "encryption-only" p

[sqlite] Inefficient covering index used for Subversion with SQLite 3.8.0

Hi, Using the Subversion 1.7 / 1.8 wc.db schema I get quite different results from the query planner for several of our queries, where the difference in performance is quite huge. For this typical example using 3.8.0.1 only one index component is used: $ EXPLAIN QUERY PLAN

Re: [sqlite] Splitting a monolithic table into two related ones.

First I must apologise for the dreadful formatting. I didn't realise my columns were broken when I copied and pasted the text until the message had been saved and I could not edit the post afterwards. > The ItemData ID can be looked up with a correlated subquery: > > INSERT INTO ItemHistory( >

[sqlite] Question about index usage

I've got a very simple example table and index: CREATE TABLE DevProps ( CompID INTEGER NOT NULL, PropID INTEGER NOT NULL ); CREATE UNIQUE INDEX Ind_DevProps_CompIDPropID on DevProps (CompID, PropID); When I check the query plan for this statement: SELECT CompID FROM DevProps WHERE PropID=33 it

[sqlite] Inefficient covering index used for Subversion with SQLite 3.8.0

Hi, Using the Subversion 1.7 / 1.8 wc.db schema I get quite different results from the query planner for several of our queries, where the difference in performance is quite huge. For this typical example using 3.8.0.1 only one index component is used: $ EXPLAIN QUERY PLAN

Re: [sqlite] to encrypt sqlite db

That last sentence is quite weird, a good encryption system should give a random-like sequence even with very low-entropy input. On the other hand removing patterns definitely cannot hurt. On Sat, Aug 31, 2013 at 4:38 PM, Etienne wrote: >> Thank you for your quick response. >> >> I am looking fo

Re: [sqlite] to encrypt sqlite db

> Thank you for your quick response. > > I am looking for freeware. If freeware not available, I have to implement > encryption support for sqlite on winrt. > > What is the procedure to implement encryption support on winrt? > > Thanks, > dd

Re: [sqlite] to encrypt sqlite db

SQLCipher is free. But it's not compatible with WinRT. I'm pretty sure that right now there is nothing that meets both of your requirements. -- E On Aug 31, 2013, at 8:52 AM, dd wrote: > Thank you for your quick response. > > I am looking for freeware. If freeware not available, I have to

Re: [sqlite] to encrypt sqlite db

Thank you for your quick response. I am looking for freeware. If freeware not available, I have to implement encryption support for sqlite on winrt. What is the procedure to implement encryption support on winrt? Thanks, dd On Sat, Aug 31, 2013 at 6:34 PM, Stephan Beal wrote: > On Sat, Aug 3

Re: [sqlite] VACUUM silently fails, database size not changed

On 08/31/2013 08:29 PM, Mario M. Westphal wrote: I run the VACUUM command at the end of a diagnosis and cleanup operation on my database. I use the SQLite 3 API on Windows 7. Latest version of SQLite. My database uses the WAL mode. The database size is 120 MB when I run the sqlite3_execute("VA

[sqlite] VACUUM silently fails, database size not changed

I run the VACUUM command at the end of a diagnosis and cleanup operation on my database. I use the SQLite 3 API on Windows 7. Latest version of SQLite. My database uses the WAL mode. The database size is 120 MB when I run the sqlite3_execute("VACUUM",...) command. After about 20 seconds of heavy

Re: [sqlite] to encrypt sqlite db

On Sat, Aug 31, 2013 at 2:59 PM, Mohit Sindhwani wrote: > Adding on to Paolo's answer, see this: http://www.hwaci.com/sw/** > sqlite/prosupport.html > See SEE and CEROD on that page. > @devs: minor typo on that page: "The SQLite software free and

Re: [sqlite] to encrypt sqlite db

On 31/8/2013 8:40 PM, Paolo Bolzoni wrote: There is a non-free version of sqlite that encrypt the db. If it is that you want then you have to contact them directly. Otherwise just use sqlite on a EncFs mounted disk? Adding on to Paolo's answer, see this: http://www.hwaci.com/sw/sqlite/prosup

Re: [sqlite] to encrypt sqlite db

There is a non-free version of sqlite that encrypt the db. If it is that you want then you have to contact them directly. Otherwise just use sqlite on a EncFs mounted disk? On Sat, Aug 31, 2013 at 2:25 PM, dd wrote: > Hi All, > > I have to encrypt sqlite database on winrt. > > What are all t

[sqlite] to encrypt sqlite db

Hi All, I have to encrypt sqlite database on winrt. What are all the necessary steps to do to encrypt sqlite database? Thanks in advance. Regards, dd ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/li