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
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 that,
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 applicati
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 th
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 bonu
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 side
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""
(procedure
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 then using rsync to
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 ::= command
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 ParseTOKENTYPE void*
not int as stated.
Thanks, Conor.
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.
Can you send in sufficient i
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 ParseTOKENTYPE void*
>
> not int as sta
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 correctly.
>
> An assertion fault is always a bug.
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 ne
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 en
> 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
tha
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 cal
> 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
hopefully eliminate redundant
> 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 has mentioned SQLCipher
(htt
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 register
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 function used in the
> W
> 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 the SQLite 3.15.0
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
RTREE or JSON.
If you a
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
24 matches
Mail list logo