Re: [sqlite] Changing ID's to UUID

On 17 Nov 2016, at 3:13am, Keith Medcalf wrote: > You would only get guaranteed collision avoidance if you kept track of every > UUID issued and checked for duplicates at time of issue to avoid duplication > by keeping a list of all the "used" identifiers. I do not think

Re: [sqlite] Changing ID's to UUID

> As someone mentioned in a different part of this thread, the issue is > centralization. If you have multiple decentralied machines generating > UUIDs you *could* have collisions, but if you pick your UUID scheme well > enough collisions will be extremely rare, on par with things like data >

Re: [sqlite] Changing ID's to UUID

On Wed, Nov 16, 2016 at 02:51:35PM -0600, Jeffrey Mattox wrote: > I think this discussion is about apples and oranges. UUID stands for > universally UNIQUE identifier, so there won't be any collisions. It > looks random, but it never repeats. [...] No, DRH is right that this depends on how

Re: [sqlite] Changing ID's to UUID

https://xkcd.com/221/ "The generation of random numbers is too important to be left to chance." -I forget who A UUID is basically a 16 byte integer that people agree to type out in a standard way. All the properties of UUID's that you've mentioned below depend on the random number generator

Re: [sqlite] Issue with Malformed table

If you are unsucessful dro me an email - I might be able to help (not a commercial proposition - just may help me doing some testing with my code) Cheers Paul www.sandersonforensics.com skype: r3scue193 twitter: @sandersonforens Tel +44 (0)1326 572786

Re: [sqlite] Changing ID's to UUID

On Wed, Nov 16, 2016 at 02:51:35PM -0600, Jeffrey Mattox wrote: > On Nov 16, 2016, at 8:46 AM, Richard Hipp wrote: > > > >> On 11/16/16, Keith Medcalf wrote: > >> What I do not > >> understand is why one would use a UUID (randomly generated bunch of bytes)

Re: [sqlite] Changing ID's to UUID

On Nov 16, 2016, at 8:46 AM, Richard Hipp wrote: > >> On 11/16/16, Keith Medcalf wrote: >> What I do not >> understand is why one would use a UUID (randomly generated bunch of bytes) >> as a key in a database. It is long, every use must be checked for >>

Re: [sqlite] Uninitialized memory reads (not likely false positives)

On Wed, Nov 16, 2016 at 12:06:39PM -0600, Nico Williams wrote: > On Tue, Nov 15, 2016 at 09:38:11PM -0200, Bernardo Sulzbach wrote: > > if( s1>7 && s2>7 ){ > > res = s1 - s2; > > }else{ > > if( s1==s2 ){ > > // Accesses to aLen as mentioned above > > > > If s1 > 7 && s2 > 7 is

Re: [sqlite] Uninitialized memory reads (not likely false positives)

On Wed, Nov 16, 2016 at 10:52:13PM +0700, Dan Kennedy wrote: > On 11/16/2016 05:53 AM, Nico Williams wrote: > > [...] > > > > Anyways, the analysis from here is non-trivial, and I can't convince > > myself that sNC.pNext will not be dereferenced. > > Thanks for taking the time to look into these.

Re: [sqlite] Uninitialized memory reads (not likely false positives)

On Tue, Nov 15, 2016 at 09:38:11PM -0200, Bernardo Sulzbach wrote: > if( s1>7 && s2>7 ){ > res = s1 - s2; > }else{ > if( s1==s2 ){ > // Accesses to aLen as mentioned above > > If s1 > 7 && s2 > 7 is false, then at least one of s1 and s2 is not above 7. > If they are equal, then

Re: [sqlite] Changing ID's to UUID

On Wed, 16 Nov 2016 08:59:03 -0600 Paul Egli wrote: > > Using the systemid sequence and the recordid sequence directly > > however, has a 0% probability of collision, so any rational person > > would use that directly and forgo entirely the introduction of > > uncertainty

Re: [sqlite] Uninitialized memory reads (not likely false positives)

On 11/16/2016 05:53 AM, Nico Williams wrote: I don't normally pay attention to warnings when compiling SQLite3, nor to Coverity or other static analysis tools' output either, as I'm quite aware that most of these are false positives and thus unwelcome noise here. However, I do sample them

Re: [sqlite] Issue with Malformed table

On 16 Nov 2016, at 3:16pm, Andrew Stewart wrote: > Forgot to ask 1 thing. What is a quick way to copy an entire table > from database1 to database2? If they are open in different connections you cannot do it. If they are open in the same connection using

Re: [sqlite] Issue with Malformed table

On 16 Nov 2016, at 3:14pm, Andrew Stewart wrote: > >Thank you for the response. I will give it a try. I can do this with > 2 different database connections and then just transfer all of the tables > from database1 to database2. Close database1.

Re: [sqlite] Issue with Malformed table

Simon, Forgot to ask 1 thing. What is a quick way to copy an entire table from database1 to database2? Thanks, Andrew -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Andrew Stewart Sent: Wednesday, November 16, 2016 7:16

Re: [sqlite] Issue with Malformed table

Simon, Thank you for the response. I will give it a try. I can do this with 2 different database connections and then just transfer all of the tables from database1 to database2. Close database1. Remove/rename the file for database1. Close database2. Rename file for database2 to

Re: [sqlite] Issue with Malformed table

On 16 Nov 2016, at 2:52pm, Andrew Stewart wrote: >I have a table that is giving me errors. I can recover the > data from another source, but need a way to clear the table. This process is very fast and easy, but it may not help with your form of

Re: [sqlite] Changing ID's to UUID

On Wed, Nov 16, 2016 at 7:59 AM, Keith Medcalf wrote: > Using the systemid sequence and the recordid sequence directly however, > has a 0% probability of collision, so any rational person would use that > directly and forgo entirely the introduction of uncertainty and bugs

[sqlite] Issue with Malformed table

Hi, I have a table that is giving me errors. I can recover the data from another source, but need a way to clear the table. The following is my process: Read row from table1 - detect error (SQL logic error or missing database). Have been able to read other rows from same

Re: [sqlite] Changing ID's to UUID

On 11/16/16, Keith Medcalf wrote: > What I do not > understand is why one would use a UUID (randomly generated bunch of bytes) > as a key in a database. It is long, every use must be checked for > collisions, and inherently far less efficient than the simple integer >

Re: [sqlite] Changing ID's to UUID

> > I still cannot fathom why anyone would assign random numbers or (even > more useless) long random blobs to use as psuedo-keys. It just boggles > the mind. > I take it you’re not a cryptographer :) All modern ciphers do this. For > example, an RSA key pair is simply a pair of large random

Re: [sqlite] Database corruption, and PRAGMA fullfsync on macOS

On 11/16/16, Simon Slavin wrote: > > There's also a tool from the SQLite team which can analyze a corrupt SQLite > file and tell some things about how it is corrupt. Unfortunately I can't > remember what it's called or where to find it. But I heard about it on this > list

Re: [sqlite] SQLite as a Shell Script

Not true. You can go ahead and create a database called "ls", but: a) it will not be executable, and b) the file will start with "SQLite format 3" rather than the requisite "#!/bin/busybox ash" So the sysadmin would still have to manually execute the "script" with an appropriate shell. -Rowan

Re: [sqlite] Database corruption, and PRAGMA fullfsync on macOS

On 16 Nov 2016, at 7:25am, Jens Alfke wrote: > The case I’m concerned about happens on Macs, as I said, and the developer > says he can trigger it in his app via a power failure or a forced shutdown > (holding the power button for 5 seconds.) This version of our library is

Re: [sqlite] SQLite as a Shell Script

well, if you have a sysadmin that has "." in their path, you could write a database called "ls" or common misspellings of commands, and that way execute arbitrary code if the sysadmin visits the system. Wout. On Wed, Nov 16, 2016 at 11:43 AM Rowan Worth wrote: > Interesting but

Re: [sqlite] SQLite as a Shell Script

Interesting but doesn't seem overly practical. If you're in a postiion to run 'busybox ash /foo/bar' then you can easily create a shell script through simpler means. Filesystem access via ATTACH DATABASE is worth bringing attention to though, as I think a lot of developers wouldn't expect that.