[sqlite] Happy New 2020 to everyone on the list...

[Jose Isaias Cabrera]

Dr. Hipp, and the SQLite team, the sqlite-users group, happy new year!  I wish 
the best for everyone here, but better yet, that you find TRUE not be FALSE.

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Causal profiling

[Jose Isaias Cabrera]

D Burgess, on Wednesday, January 1, 2020 08:19 PM, wrote...
>
> > I’ve spent too much time lately trying to figure out or debug
> hellacious C spaghetti code
>
> And I’ve spent too much time lately trying to figure out or debug
> hellacious C++ spaghetti code
>
> Someone who writes bad C,   will write even worse C++

Very true.  And for that matter, any other language too.  Except assembler. ;-)

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Hex Password with System.Data.Sqlite (.Net Core)

[Mike King]

I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
System.Data.Sqlite. How do I change / set a database password if my
password is a byte array? (It looks like I can use Pragma Key= if my
password is text).

Many Thanks, Happy New Year and apologies if this has been asked before (I
searched the mailing list archive but couldn't find an answer).

Cheers
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Virtual table OR constraint bug

[Lalit Maganti]

Hi all,

I believe that I have found a bug in the virtual table bytecode generation
when OR constraints are present and argvIndex is set in xBestIndex but the
application does not actually filter fully.

The problem seems to be in not setting/unsetting the non-null flag
correctly (SQLITE_JUMPIFNULL) on the instruction which does the comparison;
this leads to NULLs slipping through the filter.

To fully repro the problem, please find attached a small C file which shows
the unexpected behaviour. By adding an EXPLAIN in-front of the SELECT
query, you should be able to see the incorrect bytecode on the NE opcode.

If the attachment doesn't come through for some reason, I've also put the
same file as a GitHub gist
.

Thank you!

Regards,
Lalit
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Undefined behavior in fopen64 in sqlite3

[Yongheng Chen]

Hi,

We found an undefined behavior in sqlite. Here’s the POC:
—
DELETE FROM zipfile WHERE NULL BETWEEN ( 2) AND 1 ;
—-

When compiled with `-fsanitize=address`, it got a crash. We found that it’s 
because it tries to use `fopen64(NULL, “ab+”)` in zipfileBegin. And fopen64 
with NULL seems an undefined behavior. So we think developers might want to fix 
it in order to avoid undefined behaviors in sqlite to make it more robust.


Yongheng & Rui
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Question about passwords in System.Data.Sqlite

[Mike King]

Hi,

This is my third attempt to send the following message to the list and each
time it gets rejected as suspected administrivia! (not sure what that is -
I guess it's a US English word but it's certainly not an English one).

I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
System.Data.Sqlite. How do I change / set a database password if my
password is a byte array? It looks like I can use Pragma Key= if my
password is text but I use hex passwords.

Thanks
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Simon Slavin]

On 3 Jan 2020, at 12:44am, Mike King  wrote:

> Ok thanks. As this is a hobby project I don't have any cash for commercial
> extensions.

So the question becomes whether you actually need encryption in your hobby 
project, or you were just using encryption because you started off with an 
encrypted database.

There are free encryption extensions for SQLite.  But the world doesn't seem to 
have standardised on any one of them.  Which suggests that there's not one of 
them much better than the others.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Doug]

I asked for some information from Emery Berger about his video talk on 
performance where he said they got a 25% improvement in SQLite performance. 
Here is the reply I got back.

 

I know there has been a lot of talk about what can and cannot be done with the 
C calling interface because of compatibility issues and the myriad set of 
wrappers on various forms. I’m having a hard time letting go of a possible 25% 
performance improvement.

 

I don’t have the slightest idea on how to run a benchmark (but I could learn). 
I wonder if the current set of benchmarks used by SQLite developers actually 
measure throughput using wall-clock numbers. It might be a good idea to put a 
wrapper around all the benchmarks to capture how long they took to run 
(wall-clock), and include things like number and type of cpu cores, average cpu 
busy time, and other relevant numbers. If the benchmarks are run on lots of 
different machines (all over the world?), it would provide an excellent view of 
what changes in SQLite made a difference in performance.

 

Doug

 

From: Curtsinger, Charlie  
Sent: Thursday, January 02, 2020 10:55 AM
To: dougf@comcast.net
Cc: Emery D Berger 
Subject: Re: Questions about your "Performance Matters" talk re SQLite

 

Hello Doug,

 

I was able to track down the sqlite benchmark I ran for the paper, and I’ve 
checked it into the github repository at 
https://github.com/plasma-umass/coz/tree/master/benchmarks/sqlite. This 
benchmark creates 64 threads that operate on independent tables in the sqlite 
database, performing operations that should be almost entirely independent. 
This benchmark exposes contention inside of sqlite, since running it with a 
larger number of hardware threads will hurt performance. I see a performance 
improvement of nearly 5x when I run this on a two-core linux VM versus a 
64-thread Xeon machine, since there are fewer opportunities for the threads to 
interfere with each other.

 

You can also find the modified version of sqlite with the same benchmark at 
https://github.com/plasma-umass/coz/tree/master/benchmarks/sqlite-modified. 
There are just a few changes from indirect to direct calls in the sqlite3.c 
file.

 

I reran the experiment on the same machine we used for the original Coz paper, 
and saw a performance improvement of around 20% with the modified version of 
sqlite. That’s slightly less than what we originally found, but I didn’t do 
many runs (just five) and there’s quite a bit of variability. The compiler has 
been upgraded on this machine as well, so there could be some effect there as 
well. On a much-newer 64-thread Xeon machine I see a difference of just 5%, 
still in favor of the modified version of sqlite. That’s not terribly 
surprising, since Intel has baked a lot of extra pointer-chasing and branch 
prediction smarts into processors in the years since we set up the 64-core AMD 
machine we originally used for the Coz benchmarks.

 

As far as measuring performance, I’d encourage you *not* to use cpu cycles as a 
proxy for runtime. Dynamic frequency scaling can mess up these measurements, 
especially if the clock frequency is dropped in response to the program’s 
behavior. Putting many threads to sleep might allow the OS to drop the CPU 
frequency, thereby reducing the number of CPU cycles. That doesn’t mean the 
program will actually run in a shorter wall clock time. Some CPUs have a 
hardware event that counts “clock cycles” at a constant rate even with 
frequency scaling, but these are really just high-precision timers and would be 
perfectly fine for measuring runtime. I’m thinking of the “ref-cycles” event 
from perf here.

 

Hope this helps,

- Charlie

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Mike King]

I'll be honest I'm not sure. I'm using the whatever encryption comes with
the nuget package for Core 3.1.

Should I be using a specific encryption extension? When I used the .Net
Framework SQLite lib I always used the encryption that came with it.

Cheers

On Thu, 2 Jan 2020 at 22:57, Joe Mistachkin  wrote:

>
> Which encryption extension are you using?
>
> Sent from my iPhone
>
> > On Jan 2, 2020, at 5:48 PM, Mike King  wrote:
> >
> > Hi,
> >
> > This is my third attempt to send the following message to the list and
> each
> > time it gets rejected as suspected administrivia! (not sure what that is
> -
> > I guess it's a US English word but it's certainly not an English one).
> >
> > I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
> > System.Data.Sqlite. How do I change / set a database password if my
> > password is a byte array? It looks like I can use Pragma Key= if my
> > password is text but I use hex passwords.
> >
> > Thanks
> > ___
> > sqlite-users mailing list
> > sqlite-users@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> >
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Keith Medcalf]

Indeed turning off memstatus leads to a 500% (from ~3s to ~0.5s) performance 
increase.  
Changing the threading mode or the indirection level of the mutexes calls seems 
to have no significant effect.

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users  On
>Behalf Of Richard Hipp
>Sent: Thursday, 2 January, 2020 16:00
>To: SQLite mailing list 
>Subject: Re: [sqlite] FW: Questions about your "Performance Matters" talk
>re SQLite
>
>On 1/2/20, Barry Smith  wrote:
>> One thing that really stands is “creates 64 threads that operate on
>> independent tables in the sqlite database, performing operations that
>should
>> be almost entirely independent.”
>>
>
>Looking at the main.c file
>(https://github.com/plasma-
>umass/coz/blob/master/benchmarks/sqlite/main.c)
>it appears that the test creates 64 separate database connections,
>each with a separate in-memory database.
>
>There are two sources of contention here:
>
>(1) SQLite keeps track of the total amount of memory it is using on
>all threads.  So for each malloc() and free() it has to take a mutex
>to increase or decrease the counters.  This is probably the primary
>source of contention.  It can be disabled by running:
>
>sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);
>
>early in main(), before any other SQLite interface calls.  Make that
>one change and I suspect that most of the thread contention will go
>away.
>
>(2) SQLite has a single PRNG used by all threads.  And so there is a
>mutex that has to be taken whenever a new random number is generated.
>But the workload does not appear to be using any random numbers, so I
>doubt that this is an actual problem in this case.
>
>> I’d encourage you *not* to use cpu cycles as a proxy for runtime.
>Dynamic frequency
>> scaling can mess up these measurements, especially if the clock
>frequency is dropped
>> in response to the program’s behavior.
>
>The task requires X number of CPU cycles *regardless* of the clock
>frequency.  If the clock slows down, then it takes more elapse time to
>run those X cycles, but it does not increase or decrease the number of
>cycles required.  So in that sense, counting the number of CPU cycles
>is an excellent measure of effort required to complete the
>computation.
>
>Furthermore, the idea that thread contention will cause the CPU clock
>to slow down seems silly.  Technically, I suppose such a think might
>actually happen - IF you do all of your work as multiple threads
>within the same process and they all blocked on the same resource.
>The point is, you shouldn't do that.  Instead of one process with 64
>threads, how about 64 processes with one thread each.  Since they are
>all doing different things (serving independent HTTP requests, for
>example) they might as well each have their own address space.
>Keeping each job in a separate process provides isolation for added
>security.  And it completely eliminates the need for mutexes and the
>accompanying thread contention.
>
>If SQLite runs faster for you when you make direct calls to
>pthread_mutex_lock() rather than indirect calls, how much faster would
>it run if you completely eliminated all calls to pthread_mutex_lock()
>by putting each task in a separate process?
>
>
>--
>D. Richard Hipp
>d...@sqlite.org
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Mike King]

Ok thanks. As this is a hobby project I don't have any cash for commercial
extensions.

Cheers

On Fri, 3 Jan 2020 at 00:18, Joe Mistachkin  wrote:

>
> Mike King wrote:
> >
> > Should I be using a specific encryption extension? When I used the .Net
> > Framework SQLite lib I always used the encryption that came with it.
> >
>
> The CryptoAPI-based encryption included with System.Data.SQLite is a
> legacy feature, has known issues, and is officially unsupported.  It is
> being retained only for the purpose of backward compatibility with legacy
> applications that make use of it.  It has not been ported to .NET Core,
> nor has it been tested there.
>
> You might want to look into the commercial SEE extension, which does work
> with System.Data.SQLite on .NET Core for all supported platforms.
>
> --
> Joe Mistachkin
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Richard Hipp]

On 1/2/20, Barry Smith  wrote:
> One thing that really stands is “creates 64 threads that operate on
> independent tables in the sqlite database, performing operations that should
> be almost entirely independent.”
>

Looking at the main.c file
(https://github.com/plasma-umass/coz/blob/master/benchmarks/sqlite/main.c)
it appears that the test creates 64 separate database connections,
each with a separate in-memory database.

There are two sources of contention here:

(1) SQLite keeps track of the total amount of memory it is using on
all threads.  So for each malloc() and free() it has to take a mutex
to increase or decrease the counters.  This is probably the primary
source of contention.  It can be disabled by running:

sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);

early in main(), before any other SQLite interface calls.  Make that
one change and I suspect that most of the thread contention will go
away.

(2) SQLite has a single PRNG used by all threads.  And so there is a
mutex that has to be taken whenever a new random number is generated.
But the workload does not appear to be using any random numbers, so I
doubt that this is an actual problem in this case.

> I’d encourage you *not* to use cpu cycles as a proxy for runtime. Dynamic 
> frequency
> scaling can mess up these measurements, especially if the clock frequency is 
> dropped
> in response to the program’s behavior.

The task requires X number of CPU cycles *regardless* of the clock
frequency.  If the clock slows down, then it takes more elapse time to
run those X cycles, but it does not increase or decrease the number of
cycles required.  So in that sense, counting the number of CPU cycles
is an excellent measure of effort required to complete the
computation.

Furthermore, the idea that thread contention will cause the CPU clock
to slow down seems silly.  Technically, I suppose such a think might
actually happen - IF you do all of your work as multiple threads
within the same process and they all blocked on the same resource.
The point is, you shouldn't do that.  Instead of one process with 64
threads, how about 64 processes with one thread each.  Since they are
all doing different things (serving independent HTTP requests, for
example) they might as well each have their own address space.
Keeping each job in a separate process provides isolation for added
security.  And it completely eliminates the need for mutexes and the
accompanying thread contention.

If SQLite runs faster for you when you make direct calls to
pthread_mutex_lock() rather than indirect calls, how much faster would
it run if you completely eliminated all calls to pthread_mutex_lock()
by putting each task in a separate process?


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Joe Mistachkin]

Mike King wrote: 
> 
> Should I be using a specific encryption extension? When I used the .Net
> Framework SQLite lib I always used the encryption that came with it.
> 

The CryptoAPI-based encryption included with System.Data.SQLite is a
legacy feature, has known issues, and is officially unsupported.  It is
being retained only for the purpose of backward compatibility with legacy
applications that make use of it.  It has not been ported to .NET Core,
nor has it been tested there.

You might want to look into the commercial SEE extension, which does work
with System.Data.SQLite on .NET Core for all supported platforms.

--
Joe Mistachkin

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FW: Questions about your "Performance Matters" talk re SQLite

[Barry Smith]

One thing that really stands is “creates 64 threads that operate on independent 
tables in the sqlite database, performing operations that should be almost 
entirely independent.”

But that’s not how SQLite works - at least not when writing data. SQLite takes 
a lock on the entire database, there is no fine granularity locking that allows 
you to perform simultaneous writes to different tables.

It seems attempting to do this - use 64 threads to write to a database - is a 
highly inefficient use of the library.

> On 2 Jan 2020, at 1:54 pm, Doug  wrote:
> 
> I asked for some information from Emery Berger about his video talk on 
> performance where he said they got a 25% improvement in SQLite performance. 
> Here is the reply I got back.
> 
> 
> 
> I know there has been a lot of talk about what can and cannot be done with 
> the C calling interface because of compatibility issues and the myriad set of 
> wrappers on various forms. I’m having a hard time letting go of a possible 
> 25% performance improvement.
> 
> 
> 
> I don’t have the slightest idea on how to run a benchmark (but I could 
> learn). I wonder if the current set of benchmarks used by SQLite developers 
> actually measure throughput using wall-clock numbers. It might be a good idea 
> to put a wrapper around all the benchmarks to capture how long they took to 
> run (wall-clock), and include things like number and type of cpu cores, 
> average cpu busy time, and other relevant numbers. If the benchmarks are run 
> on lots of different machines (all over the world?), it would provide an 
> excellent view of what changes in SQLite made a difference in performance.
> 
> 
> 
> Doug
> 
> 
> 
> From: Curtsinger, Charlie  
> Sent: Thursday, January 02, 2020 10:55 AM
> To: dougf@comcast.net
> Cc: Emery D Berger 
> Subject: Re: Questions about your "Performance Matters" talk re SQLite
> 
> 
> 
> Hello Doug,
> 
> 
> 
> I was able to track down the sqlite benchmark I ran for the paper, and I’ve 
> checked it into the github repository at 
> https://github.com/plasma-umass/coz/tree/master/benchmarks/sqlite. This 
> benchmark creates 64 threads that operate on independent tables in the sqlite 
> database, performing operations that should be almost entirely independent. 
> This benchmark exposes contention inside of sqlite, since running it with a 
> larger number of hardware threads will hurt performance. I see a performance 
> improvement of nearly 5x when I run this on a two-core linux VM versus a 
> 64-thread Xeon machine, since there are fewer opportunities for the threads 
> to interfere with each other.
> 
> 
> 
> You can also find the modified version of sqlite with the same benchmark at 
> https://github.com/plasma-umass/coz/tree/master/benchmarks/sqlite-modified. 
> There are just a few changes from indirect to direct calls in the sqlite3.c 
> file.
> 
> 
> 
> I reran the experiment on the same machine we used for the original Coz 
> paper, and saw a performance improvement of around 20% with the modified 
> version of sqlite. That’s slightly less than what we originally found, but I 
> didn’t do many runs (just five) and there’s quite a bit of variability. The 
> compiler has been upgraded on this machine as well, so there could be some 
> effect there as well. On a much-newer 64-thread Xeon machine I see a 
> difference of just 5%, still in favor of the modified version of sqlite. 
> That’s not terribly surprising, since Intel has baked a lot of extra 
> pointer-chasing and branch prediction smarts into processors in the years 
> since we set up the 64-core AMD machine we originally used for the Coz 
> benchmarks.
> 
> 
> 
> As far as measuring performance, I’d encourage you *not* to use cpu cycles as 
> a proxy for runtime. Dynamic frequency scaling can mess up these 
> measurements, especially if the clock frequency is dropped in response to the 
> program’s behavior. Putting many threads to sleep might allow the OS to drop 
> the CPU frequency, thereby reducing the number of CPU cycles. That doesn’t 
> mean the program will actually run in a shorter wall clock time. Some CPUs 
> have a hardware event that counts “clock cycles” at a constant rate even with 
> frequency scaling, but these are really just high-precision timers and would 
> be perfectly fine for measuring runtime. I’m thinking of the “ref-cycles” 
> event from perf here.
> 
> 
> 
> Hope this helps,
> 
> - Charlie
> 
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Joe Mistachkin]

Which encryption extension are you using?

Sent from my iPhone

> On Jan 2, 2020, at 5:48 PM, Mike King  wrote:
> 
> Hi,
> 
> This is my third attempt to send the following message to the list and each
> time it gets rejected as suspected administrivia! (not sure what that is -
> I guess it's a US English word but it's certainly not an English one).
> 
> I'm porting some code from .Net 4.8 to .Net Core 3.1 using the latest
> System.Data.Sqlite. How do I change / set a database password if my
> password is a byte array? It looks like I can use Pragma Key= if my
> password is text but I use hex passwords.
> 
> Thanks
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> 

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Assertion `0' failed.

[Yongheng Chen]

Hi,

We found an assertion failed in sqlite. And this assertion seems not to be 
fixed completely. Here’s the POC:
—
CREATE TABLE v0 ( v8 FLOAT , v7 UNIQUE ON CONFLICT ROLLBACK GENERATED ALWAYS 
AS( v6 ) , v6 INT , v5 INT UNIQUE GENERATED ALWAYS AS( NULL ) , v4 INTEGER 
UNIQUE , v3 DOUBLE PRIMARY KEY CHECK( v6 ) , v2 VARCHAR(20) UNIQUE , v1 FLOAT 
CHECK( julianday ( 'MED P' ) ) CHECK( v6 NOT LIKE 'b' ) NOT NULL ON CONFLICT 
REPLACE UNIQUE UNIQUE ON CONFLICT ROLLBACK ) ;

CREATE VIEW v9 ( v10 ) AS SELECT v4 FROM v0 WHERE v2 = 'Brand#12' AND v6 != v1 
OR ( v1 BETWEEN 10 AND v3 ) ;

SELECT 10 FROM v9 WHERE 1 = v10 OR NULL BETWEEN ( SELECT v10 FROM v9 AS 
prep_inst WHERE NULL BETWEEN ( SELECT sum ( v8 ) OVER( ) AS myname FROM v0 AS x 
GROUP BY 1 ) AND 10 GROUP BY v10 ) AND 10 ;
—-

This exists in the latest development code built with debug flag.

Yongheng & Rui
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about passwords in System.Data.Sqlite

[Mike King]

I tend to use my hobby code as an excuse to play with and learn the stuff
that I don’t use in the daily grind. It also helps me keep up to date
(hence .Net core 3.1). So, to answer your question encryption is important
:)

Cheers

Mike

On Fri, 3 Jan 2020 at 01:27, Simon Slavin  wrote:

> On 3 Jan 2020, at 12:44am, Mike King  wrote:
>
> > Ok thanks. As this is a hobby project I don't have any cash for
> commercial
> > extensions.
>
> So the question becomes whether you actually need encryption in your hobby
> project, or you were just using encryption because you started off with an
> encrypted database.
>
> There are free encryption extensions for SQLite.  But the world doesn't
> seem to have standardised on any one of them.  Which suggests that there's
> not one of them much better than the others.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [EXTERNAL] Re: 18 minutes 41 seconds

[Hick Gunter]

> Obviously the character(s) responsible  for dates etc were NOT C programmers!

No, they still using Roman Numerals instead of Indian Numbers and were 
oblivious of the number 0. As indeed Abu Dschaʿfar Muhammad ibn Musa 
al-Chwārizmī published his book "De numero Indorum" (the earliest latin 
translation of the arabic original, which is lost) somewhere around the year 
825, that introduced their algebra (taken from the original title "al-Kitāb 
al-muḫtaṣar fī ḥisāb al-ğabr wa-ʾl-muqābala") into the arabic world; later 
translations referred to the digits 0-9 as arabic numbers.


___
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] 18 minutes 41 seconds

[Luca Olivetti]

El 31/12/19 a les 4:06, Keith Medcalf ha escrit:


On Monday, 30 December, 2019 19:29, Michael Falconer 
 wrote:


As we approach the end of yet another year ( and indeed decade ).


Technically, every year is the end of a decade, if one means the immediately 
preceding ten years.

However, if you mean the end of the second decade of the 21st century, you will 
have to wait another year for that.  January 1st, 0001 AD was the first day of 
the year 1.  The first decade ended at the end of December 31st 0011 AD, not 
December 31st, 0010 AD. (if following the proleptic Gregorian calendar).


https://xkcd.com/2249/

scnr


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users