Re: [sqlite] Protecting databases

On 2016/10/08 1:12 PM, Damien Sykes-Lindley wrote: Hi Ryan, I think there may have been some misunderstanding here. The application is a local application and thus needs no server, at least on the data side. But multiple people may have access to the same machine. So while user control is

Re: [sqlite] Fwd: Lemon: Simple recursive rule causes assertion failed: stateno <= YY_SHIFT_COUNT

On 8 October 2016 at 14:31, Richard Hipp wrote: > On 10/8/16, Conor O wrote: > > Assertion failed: stateno <= YY_SHIFT_COUNT, file testpar.c, line 512 > > > > I'm trying to figure out if this is a bug or something I'm just not > > understanding

Re: [sqlite] Protecting databases

If you are trying to protect against casual snooping, you could probably zip the sqlite data with a password then have your application unzip the data to a temp location on open, then re-zip at the end, deleting the unzipped file. Your application then would be able to use the normal sqlite

Re: [sqlite] Protecting databases

If you're developing in Windows, you could leave it to the file system, but could be dangerous, and then binds you to using an NTFS based OS. NTFS has the capability of doing file level encryption, and you can flip the flag on the file to have the filesystem encrypt the file. The catch is, the

Re: [sqlite] Fwd: Lemon: Simple recursive rule causes assertion failed: stateno <= YY_SHIFT_COUNT

> Absolutely! I've simplified some source code and attached two files testlex.c > and testpar.c. > I'm not sure if the mailing list strips out attachments I guess it does strip attachments. For the benefits of the mailing list, I'll inline the code (assuming gmail doesn't mess it up more

Re: [sqlite] Backward compatibility of indexes with "WHERE function()"

On 10/8/16, Jens Alfke wrote: > What’s the compatibility of the new partial indexes* with deterministic > functions in their WHERE clauses? > I.e. if I create such an index, and then later the database is opened by an > older version of SQLite, what happens? (Let’s say the

Re: [sqlite] Protecting databases

> On Oct 7, 2016, at 10:46 PM, Damien Sykes-Lindley > wrote: > > I cannot see any means of password protecting the database without either > buying a commercial extension to do this, or recompiling SQLite with the > authentication extension. I’m surprised no one

Re: [sqlite] Parallel access to read only in memory database

> On Oct 7, 2016, at 1:45 PM, Joe Mistachkin wrote: > > Have you tried using the URI "file::memory:?cache=shared” Shared cache will definitely help when using multiple read-only connections, but I have a feeling memory-mapping would help even more since it would

[sqlite] Backward compatibility of indexes with "WHERE function()"

What’s the compatibility of the new partial indexes* with deterministic functions in their WHERE clauses? I.e. if I create such an index, and then later the database is opened by an older version of SQLite, what happens? (Let’s say the function used in the WHERE clause is still properly

Re: [sqlite] Backward compatibility of indexes with "WHERE function()"

> On Oct 8, 2016, at 12:56 PM, Richard Hipp wrote: > > Databases that use functions in the WHERE clause of a partial index > will be unreadable by any version of SQLite prior to 3.15.0. Yikes! This would be good to call out in the docs. > Why can't you statically link against

Re: [sqlite] Backward compatibility of indexes with "WHERE function()"

On 10/8/16, Jens Alfke wrote: > > SQLite is only about 1MB of > code(?) See http://sqlite.org/graphs/size-20161009.jpg for a graph of compiled-binary size using gcc 4.8.4 and -Os on x64 Linux. Less than 0.5 MB, though to be fair this is without extensions such as FTS5 or

Re: [sqlite] Protecting databases

Hello Damien, I use the "encrypt specific fields" method of encrypting data in sqlite. For you to use that with Basic you'd probably have to find or write a wrapper DLL which handled the field encryption. So your basic would only see unencrypted data after it sent a password to the

Re: [sqlite] Protecting databases

Hi Darren, You are correct in that genealogy is generally public. However more often than not the information you want to publish may very well differ from what is in your private database. You may have private notes telling you what you need to do. You may have anecdotes shared by many family

Re: [sqlite] Protecting databases

So, if you don't want to pay the one-time fee for the SQLite Encryption Extension et al to get database-level security, your only option really is to encrypt individual fields at the application level that you want to protect, and there are various free encryption libraries you can use for

Re: [sqlite] Protecting databases

Replying to myself. This being said, going for the application-level encryption option would prevent you from using SQLite to do some useful things, such as being able to do a substring search for text in encrypted fields, since encrypted data is just a black box to it. Typically the

Re: [sqlite] Protecting databases

Damien, At 09:18 08/10/2016, you wrote: Password protecting it is also good on many levels - if the database is to be used online then it is needless to say that authentication would be required for various people to view it. SQLite can't be put "online" per se. It will then be the duty of

Re: [sqlite] Protecting databases

Hi Damien, We are obviously all fans of SQLite and keen to involve more people in what is one of the best DB systems in existence and most widely used DB in the World. But... SQLite answers a need that is quite specific (though widely used) in that it is very small, very fast and, as a

Re: [sqlite] Protecting databases

Hi Ryan, I think there may have been some misunderstanding here. The application is a local application and thus needs no server, at least on the data side. But multiple people may have access to the same machine. So while user control is needed elsewhere, that certainly isn't on the local

Re: [sqlite] Error trying to make sqlite3 documentation

On 10/8/16, Domingo Alvarez Duarte wrote: > Hello ! > > I'm trying to make sqlite3 documentation to use locally and got this error: > > Has someone build the latest documentation ? > Yes. https://sqlite.org/draft/index.html was built by typing "make all" (or "make fast") and

[sqlite] Error trying to make sqlite3 documentation

Hello ! I'm trying to make sqlite3 documentation to use locally and got this error: make all ... Processing ./pages/btreemodule.in ./tclsh: missing close-brace while executing "hd_puts {" ("eval" body line 590) invoked from within "eval "hd_puts \173$text\175""

[sqlite] Fwd: Lemon: Simple recursive rule causes assertion failed: stateno <= YY_SHIFT_COUNT

I've been experimenting with some simple rules as I get used to the Lemon parser. This very simple parser file works correctly. A database consists of an entrylist which consists of any number of commands: database ::= entrylist. { printf("Constructed the root\n"); } entrylist ::=

Re: [sqlite] Fwd: Lemon: Simple recursive rule causes assertion failed: stateno <= YY_SHIFT_COUNT

On 10/8/16, Conor O wrote: > Assertion failed: stateno <= YY_SHIFT_COUNT, file testpar.c, line 512 > > I'm trying to figure out if this is a bug or something I'm just not > understanding correctly. An assertion fault is always a bug. This is true of any application.

Re: [sqlite] Lemon documention (small error)

On 10/8/16, Conor O'Rourke wrote: > I believe the Lemon documentation at: > http://www.hwaci.com/sw/lemon/lemon.html is out of date with respect to the > default token type. If I create a parser with no token_type override, the > default type is: > > #define