Re: [sqlite] Unsigned

2018-08-22 Thread D Burgess
To answer Jens - electronic IDs. And yes I use bignums on the client side. Note that I have workarounds and the system I have is stable and works, I just rue not having 64 bits and UNSIGNED indexes. There was additional work to get it all going in SQLite. I probably would not have originally

Re: [sqlite] Unsigned

2018-08-22 Thread Thomas Kurz
+1 for that or a true bignum support (i.e. without any length restriction). The latter would be perfect as it would provide support for storing numbers of encryption keys (RSA, etc.). And it would also avoid the problem of having to extend the bigint range again in a couple of years. -

Re: [sqlite] Unsigned

2018-08-22 Thread Simon Slavin
On 22 Aug 2018, at 6:04pm, Jens Alfke wrote: > Bignums make unsigned types irrelevant, if the only reason you need unsigned > is to store 64-bit positive integers. As others have said, "unsigned" is a > constraint, not a type. Agreed. > Bignums would be nice; but you could implement them

Re: [sqlite] Unsigned

2018-08-22 Thread Jens Alfke
> On Aug 22, 2018, at 10:04 AM, Randall Smith wrote: > > BLOBs are useful for storage of binary info (e.g., a file), but they are not > human readable and require complex conversion when inserting and extracting > info from the DB. *Shrug* I work with lots of non-human-readable data so I

Re: [sqlite] Unsigned

2018-08-22 Thread Randall Smith
>>> From: D Burgess >>> You can just store [large integers as] binary blobs and interpret then in >>> the client, no? Or do >>> you need to do arithmetic on them? BLOBs are useful for storage of binary info (e.g., a file), but they are not human readable and

Re: [sqlite] Unsigned

2018-08-22 Thread Jens Alfke
> On Aug 21, 2018, at 9:54 AM, Randall Smith wrote: > > I would like to enthusiastically second not only this as a feature request, > but also request arbitrary-length (or at least much longer length) INTEGER > values, as are possible in other SQL dialects. Bignums make unsigned types

[sqlite] [System.Data.SQLite] BusyTimeout and DefaultTimeout are not picked up from the connection string

2018-08-22 Thread Phani Rahul Sivalenka
Hello, The question is related to the System.Data.SQLite library's connection string parsing. We have defined the connection string as follows: data source=;DateTimeKind=Utc;Version=3;Pooling=True;Synchronous=Off;journal mode=Memory;busytimeout=30001;default timeout=31 When a new

[sqlite] [Lemon] report file description

2018-08-22 Thread Oleg
Hi, all. Can anybody help me with interpretation of lemon report file? For example, i have the next report part: State 10: (2) head ::= init_stmts * init_stmts ::= init_stmts * init_stmt init_stmt ::= * WORD init_stmt_prms SEMICOLON WORD

Re: [sqlite] Variable value vs Static inside the Sqlite datetime function.

2018-08-22 Thread Richard Hipp
On 8/21/18, Fim Wästberg wrote: > Will I works even If the date is 2018-12-18 ? How hard is it to try and see for yourself? -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Variable value vs Static inside the Sqlite datetime function.

2018-08-22 Thread Fim Wästberg
Will I works even If the date is 2018-12-18 ? Fim Wästberg, Sweden -Ursprungligt meddelande- Från: sqlite-users För Richard Hipp Skickat: den 21 augusti 2018 13:01 Till: SQLite mailing list Ämne: Re: [sqlite] Variable value vs Static inside the Sqlite datetime function. On 8/19/18,

Re: [sqlite] Unsigned

2018-08-22 Thread Olivier Mascia
> Le 22 août 2018 à 00:46, D Burgess a écrit : > > I currently store them as blobs. A lot of them, 16 bytes (versus > numeric 8 per item). > And not optimal for indexes. Why would you need or use 16 bytes to store the 8 bytes of a 64 bits integer as a blob? -- Best regards, Meilleures