auto-incrementing integer in composite primary key

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

auto-incrementing integer in composite primary key

Puneet Kishor-2
Given

        CREATE TABLE t (
                id INTEGER NOT NULL,
                created_on DATETIME DEFAULT CURRENT_TIMESTAMP
                PRIMARY KEY (id, created_on)
        );

how can I make just the 'id' column auto-increment?


--
Puneet Kishor
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Patrik Nilsson-2
You can use:

create table t ( id integer primary key autoincrement, created_on
DATETIME DEFAULT CURRENT_TIMESTAMP )

Patrik

On 04/16/2012 06:27 PM, Mr. Puneet Kishor wrote:

> Given
>
> CREATE TABLE t (
> id INTEGER NOT NULL,
> created_on DATETIME DEFAULT CURRENT_TIMESTAMP
> PRIMARY KEY (id, created_on)
> );
>
> how can I make just the 'id' column auto-increment?
>
>
> --
> Puneet Kishor
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Puneet Kishor-2

On Apr 16, 2012, at 11:47 AM, Patrik Nilsson wrote:

> You can use:
>
> create table t ( id integer primary key autoincrement, created_on
> DATETIME DEFAULT CURRENT_TIMESTAMP )
>
>



No, the above will create a PK on only the 'id' column. I want a composite PK with 'id' and 'created_on' columns, but 'autoincrement' keyword seems to work only with 'primary key' invocation.



>
> On 04/16/2012 06:27 PM, Mr. Puneet Kishor wrote:
>> Given
>>
>> CREATE TABLE t (
>> id INTEGER NOT NULL,
>> created_on DATETIME DEFAULT CURRENT_TIMESTAMP
>> PRIMARY KEY (id, created_on)
>> );
>>
>> how can I make just the 'id' column auto-increment?
>>
>>
>> --
>> Puneet Kishor

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Simon Slavin-3
In reply to this post by Puneet Kishor-2

On 16 Apr 2012, at 5:27pm, "Mr. Puneet Kishor" <[hidden email]> wrote:

> Given
>
> CREATE TABLE t (
> id INTEGER NOT NULL,
> created_on DATETIME DEFAULT CURRENT_TIMESTAMP
> PRIMARY KEY (id, created_on)
> );
>
> how can I make just the 'id' column auto-increment?

If there was a syntax it would be

        CREATE TABLE t (
                id INTEGER AUTOINCREMENT,
                created_on DATETIME DEFAULT CURRENT_TIMESTAMP
                PRIMARY KEY (id, created_on)
        );

so try that.  But the diagram on

http://www.sqlite.org/lang_createtable.html

suggests that AUTOINCREMENT can be used only as part of the PRIMARY KEY definition.

Another way to do it might be to use a TRIGGER to look up the current MAX() value of the column and add 1 to it.  (I believe you can't do this as a DEFAULT.)

So you'd define a TRIGGER on INSERT which looked to see if new.id is NULL and if it is, sets new.id to max(id)+1 .  I have no idea whether this would actually work.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Igor Tandetnik
In reply to this post by Puneet Kishor-2
On 4/16/2012 12:51 PM, Mr. Puneet Kishor wrote:

>
> On Apr 16, 2012, at 11:47 AM, Patrik Nilsson wrote:
>
>> You can use:
>>
>> create table t ( id integer primary key autoincrement, created_on
>> DATETIME DEFAULT CURRENT_TIMESTAMP )
>>
>
> No, the above will create a PK on only the 'id' column. I want a composite PK with 'id' and 'created_on' columns

Why?  What purpose do you believe a composite key would serve, that
would not be served equally well with a primary key on id column alone?

In any case, SQLite only supports AUTOINCREMENT on a column declared
INTEGER PRIMARY KEY.
--
Igor Tandetnik

_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Puneet Kishor-2

On Apr 16, 2012, at 12:32 PM, Igor Tandetnik wrote:

> On 4/16/2012 12:51 PM, Mr. Puneet Kishor wrote:
>>
>> On Apr 16, 2012, at 11:47 AM, Patrik Nilsson wrote:
>>
>>> You can use:
>>>
>>> create table t ( id integer primary key autoincrement, created_on
>>> DATETIME DEFAULT CURRENT_TIMESTAMP )
>>>
>>
>> No, the above will create a PK on only the 'id' column. I want a composite PK with 'id' and 'created_on' columns
>
> Why?  What purpose do you believe a composite key would serve, that would not be served equally well with a primary key on id column alone?
>


I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved. So, if I have

        CREATE TABLE t (
                id INTEGER,
                created_on DATETIME DEFAULT CURRENT_TIMESTAMP,
                name TEXT,
                is_trivial_update BOOLEAN DEFAULT 0,
                PRIMARY KEY (id, created_on)
        );

today I can have

        1, 2012-04-16 12:51:00, John, 0

and in the coming days I can make it

        1, 2012-04-16 12:51:00, John, 0
        1, 2012-04-17 10:00:00, Johnny, 0
        1, 2012-04-17 10:00:00, Johnnie, 1
        1, 2012-04-17 22:12:00, John Walker, 0

Then, I can get the value of id 1 on any given datetime with something like

        SELECT name, created_on
        FROM t
        WHERE
                id = 1 AND
                is_trivial_update = 0 AND
                created_on <= '2012-04-17 09:00:00'
        ORDER DESC
        LIMIT 1;

which would yield

        John, 2012-04-16 12:51:00

Any other suggestions to achieve a similar functionality would be welcome.


--
Puneet Kishor
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Simon Slavin-3

On 16 Apr 2012, at 6:58pm, Puneet Kishor <[hidden email]> wrote:

> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved. So, if I have
>
> CREATE TABLE t (
> id INTEGER,
> created_on DATETIME DEFAULT CURRENT_TIMESTAMP,
> name TEXT,
> is_trivial_update BOOLEAN DEFAULT 0,
> PRIMARY KEY (id, created_on)
> );
>
> today I can have
>
> 1, 2012-04-16 12:51:00, John, 0
>
> and in the coming days I can make it
>
> 1, 2012-04-16 12:51:00, John, 0
> 1, 2012-04-17 10:00:00, Johnny, 0
> 1, 2012-04-17 10:00:00, Johnnie, 1
> 1, 2012-04-17 22:12:00, John Walker, 0

Have one table which holds just the current data.  Use the standard primary key mechanism with that table, allowing it to supply an autoincrementing integer primary key for that table.

Have another table which lists all the changes for the first table.  The primary key for the second table can also be an autoincrementing integer primary key, but that has nothing to do with one with all the current values in it.  The 'id' column of the first table should be a different column of the second table.  Use a TRIGGER mechanism so that every INSERT and UPDATE for the first table makes an entry in the second table.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Puneet Kishor-2

On Apr 16, 2012, at 1:08 PM, Simon Slavin wrote:

>
> On 16 Apr 2012, at 6:58pm, Puneet Kishor <[hidden email]> wrote:
>
>> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved. So, if I have
>>
>> CREATE TABLE t (
>> id INTEGER,
>> created_on DATETIME DEFAULT CURRENT_TIMESTAMP,
>> name TEXT,
>> is_trivial_update BOOLEAN DEFAULT 0,
>> PRIMARY KEY (id, created_on)
>> );
>>
>> today I can have
>>
>> 1, 2012-04-16 12:51:00, John, 0
>>
>> and in the coming days I can make it
>>
>> 1, 2012-04-16 12:51:00, John, 0
>> 1, 2012-04-17 10:00:00, Johnny, 0
>> 1, 2012-04-17 10:00:00, Johnnie, 1
>> 1, 2012-04-17 22:12:00, John Walker, 0
>
> Have one table which holds just the current data.  Use the standard primary key mechanism with that table, allowing it to supply an autoincrementing integer primary key for that table.
>
> Have another table which lists all the changes for the first table.  The primary key for the second table can also be an autoincrementing integer primary key, but that has nothing to do with one with all the current values in it.  The 'id' column of the first table should be a different column of the second table.  Use a TRIGGER mechanism so that every INSERT and UPDATE for the first table makes an entry in the second table.
>

Thanks. That is one approach I have considered. I will try it out, but I am less enthusiastic about it as it would involve creating a shadow table for every table in the db. I am planning to try both approaches, evaluate, and choose among them after real experimentation.


--
Puneet Kishor
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Kit-18
In reply to this post by Puneet Kishor-2
2012/4/16 Puneet Kishor <[hidden email]>:
> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved.
> Any other suggestions to achieve a similar functionality would be welcome.
> --
> Puneet Kishor

1. Use Git or Mercurial
2. Try this:

CREATE TABLE instance  (
         filename TEXT,
         version INT,
         size INT,
         md5sum TEXT,
         creation_date TEXT,
         last_write_time TEXT,
         PRIMARY KEY(filename,version),
         FOREIGN KEY (md5sum) REFERENCES resource (md5sum)
         );

CREATE TABLE resource (
         md5sum TEXT,
         data BLOB,
         primary key(md5sum)
       );
--
Kit
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Simon Slavin-3
In reply to this post by Puneet Kishor-2

On 16 Apr 2012, at 7:11pm, Puneet Kishor <[hidden email]> wrote:

> Thanks. That is one approach I have considered. I will try it out, but I am less enthusiastic about it as it would involve creating a shadow table for every table in the db.

If you can summarise, instead of copying the columns individually, then you need only have one shadow table.  Just make the table name a column in the shadow table.

> I am planning to try both approaches, evaluate, and choose among them after real experimentation.

Another possibility would be to return to your own approach and simply have your software supply the values for new entries instead of making SQLite do it with AUTOINCREMENT.  Before each INSERT just do

BEGIN
SELECT max(id)+1 FROM theTable
INSERT ...
END

and supply the value returned from the SELECT in the INSERT command.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Richard Hipp-3
In reply to this post by Kit-18
On Mon, Apr 16, 2012 at 2:14 PM, Kit <[hidden email]> wrote:

> 2012/4/16 Puneet Kishor <[hidden email]>:
> > I am experimenting with a home-grown versioning system where every
> "significant" modification to row would be performed on a copy of the row,
> the original being preserved.
> > Any other suggestions to achieve a similar functionality would be
> welcome.
> > --
> > Puneet Kishor
>
> 1. Use Git or Mercurial
>

SQLite uses Fossil <http://www.fossil-scm.org/>



--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Puneet Kishor-2
In reply to this post by Kit-18

On Apr 16, 2012, at 1:14 PM, Kit wrote:

> 2012/4/16 Puneet Kishor <[hidden email]>:
>> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved.
>> Any other suggestions to achieve a similar functionality would be welcome.
>> --
>> Puneet Kishor
>
> 1. Use Git or Mercurial


My statement might have been misunderstood. I am not trying to create a versioning system a la Git, Mercurial or Fossil. I am trying to create a data versioning system so that a query done at a particular time can be reproduced identically as to the original query even if the data have been modified in the interim time.

So, if a query returns one or more rows today, the same query (that is, the same query params with an additional time stamp param) should return exactly the same result 3 years from now even if the rows themselves may have been modified.

In Postgres world they call it timetravel. See "F.39.2. timetravel — Functions for Implementing Time Travel" at http://www.postgresql.org/docs/9.1/static/contrib-spi.html for reference.




> 2. Try this:
>
> CREATE TABLE instance  (
>         filename TEXT,
>         version INT,
>         size INT,
>         md5sum TEXT,
>         creation_date TEXT,
>         last_write_time TEXT,
>         PRIMARY KEY(filename,version),
>         FOREIGN KEY (md5sum) REFERENCES resource (md5sum)
>         );
>
> CREATE TABLE resource (
>         md5sum TEXT,
>         data BLOB,
>         primary key(md5sum)
>       );




_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Petite Abeille-2

On Apr 16, 2012, at 8:29 PM, Puneet Kishor wrote:

> In Postgres world they call it timetravel.

Time travel? Meh...

Oracle features Total Recall!!!

http://www.orafaq.com/wiki/Oracle_Total_Recall

In a nutshell:

select *
from    foo
*as of* a point in time

Oracle Total Recall
http://www.oracle.com/technetwork/database/focus-areas/storage/total-recall-whitepaper-171749.pdf

Got to use that just for the name! :D
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Simon Slavin-3
In reply to this post by Puneet Kishor-2

On 16 Apr 2012, at 7:29pm, Puneet Kishor <[hidden email]> wrote:

> So, if a query returns one or more rows today, the same query (that is, the same query params with an additional time stamp param) should return exactly the same result 3 years from now even if the rows themselves may have been modified.

If your system can accept UPDATE commands which multiple rows, then the only way to do it correctly is to use a TRIGGER.  SQLite triggers automatically execute once per row changed.  All alternatives involve writing your own parser for SQL commands.

However, one way to achieve your requirements efficiently is extremely simple: just log all UPDATE and INSERT commands.  Save them, plus a timestamp, in a file, either a text file or a SQLite database.  When you need to reconstruct your database at any date/time, simply replay your transcript up to that data/time.

Simon.
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Pavel Ivanov-2
In reply to this post by Puneet Kishor-2
> So, if a query returns one or more rows today, the same query (that is, the same query params with an additional time stamp param) should return exactly the same result 3 years from now even if the rows themselves may have been modified.

I just want to note that to support this function you probably want to
add 2 dates to each row - one when this version's life
started and another one - when it's ended. Otherwise your queries to
the past will be very complicated (but it seems to me queries about
present are pretty complicated too).

For auto-incrementing maybe you want to implement your own auxiliary
table a-la sqlite_sequence: when you need to insert new row you select
current value from this table, update it and insert row with selected
value.


Pavel


On Mon, Apr 16, 2012 at 2:29 PM, Puneet Kishor <[hidden email]> wrote:

>
> On Apr 16, 2012, at 1:14 PM, Kit wrote:
>
>> 2012/4/16 Puneet Kishor <[hidden email]>:
>>> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved.
>>> Any other suggestions to achieve a similar functionality would be welcome.
>>> --
>>> Puneet Kishor
>>
>> 1. Use Git or Mercurial
>
>
> My statement might have been misunderstood. I am not trying to create a versioning system a la Git, Mercurial or Fossil. I am trying to create a data versioning system so that a query done at a particular time can be reproduced identically as to the original query even if the data have been modified in the interim time.
>
> So, if a query returns one or more rows today, the same query (that is, the same query params with an additional time stamp param) should return exactly the same result 3 years from now even if the rows themselves may have been modified.
>
> In Postgres world they call it timetravel. See "F.39.2. timetravel — Functions for Implementing Time Travel" at http://www.postgresql.org/docs/9.1/static/contrib-spi.html for reference.
>
>
>
>
>> 2. Try this:
>>
>> CREATE TABLE instance  (
>>         filename TEXT,
>>         version INT,
>>         size INT,
>>         md5sum TEXT,
>>         creation_date TEXT,
>>         last_write_time TEXT,
>>         PRIMARY KEY(filename,version),
>>         FOREIGN KEY (md5sum) REFERENCES resource (md5sum)
>>         );
>>
>> CREATE TABLE resource (
>>         md5sum TEXT,
>>         data BLOB,
>>         primary key(md5sum)
>>       );
>
>
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Petite Abeille-2
In reply to this post by Simon Slavin-3

On Apr 16, 2012, at 8:38 PM, Simon Slavin wrote:

> However, one way to achieve your requirements efficiently is extremely simple: just log all UPDATE and INSERT commands.  Save them, plus a timestamp, in a file, either a text file or a SQLite database.  When you need to reconstruct your database at any date/time, simply replay your transcript up to that data/time.

"In theory, there is no difference between theory and practice. But, in practice, there is." :P



_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Nico Williams
In reply to this post by Puneet Kishor-2
On Mon, Apr 16, 2012 at 12:58 PM, Puneet Kishor <[hidden email]> wrote:
> I am experimenting with a home-grown versioning system where every "significant" modification to row would be performed on a copy of the row, the original being preserved. So, if I have

There are several ways to handle this.

You could denormalize the ID into a separate table that holds... just
the ID, so that way you get your autoincrement.  Or you could use a
trigger to set the ID column (which means you must allow it to be
NULL) to the max() + 1 of the IDs. and you'll need the ID to be first
in some index (or the composite key) so that you can make that max()
run efficiently.  The denormalization-of-the-ID approach also lets you
create other sorts of stable identifiers besides integers, such as
UUIDs, say.

You'll need VIEWs to filter out all but current data.

Simon suggests moving the historical data into separate tables, which
is a good idea, except that if you want to have future changes
pre-created and take effect as time passes then the separate tables
schema doesn't work very well.

Nico
--
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Kit-18
In reply to this post by Puneet Kishor-2
2012/4/16 Puneet Kishor <[hidden email]>:
> I am trying to create a data versioning system so that a query done at a particular time can be reproduced identically as to the original query even if the data have been modified in the interim time.

CREATE TABLE doc (
      id INTEGER PRIMARY KEY autoincrement,
      record TEXT
);

CREATE TABLE t (
      id INTEGER PRIMARY KEY autoincrement,
      doc_id INTEGER,
      rec TEXT,
      created_on DATETIME DEFAULT CURRENT_TIMESTAMP,
      FOREIGN KEY(doc_id) REFERENCES doc(id)
);

SELECT doc.record, t.rec FROM doc LEFT JOIN t ON doc.id=t.doc_id
      WHERE doc.id=id_xx AND created_on<=time_xx
      ORDER BY created_on DESC LIMIT 1;

`id_xx` and `time_xx` are keys for search. You may use some additional indexes.
--
Kit
_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Petite Abeille-2
In reply to this post by Puneet Kishor-2

On Apr 16, 2012, at 8:29 PM, Puneet Kishor wrote:

> I am trying to create a data versioning system so that a query done at a particular time can be reproduced identically as to the original query even if the data have been modified in the interim time.

My 2¢ worth…

(1) Proper historization/versioning is not a piece of cake
(2) Most constraint mechanisms do not help with it

Regarding (1), I would suggest a relatively straightforward setup where all you versioned tables include a date range specifying the point in time a record is valid. This is more conveniently expressed as two fields, along the lines of valid_from and valid_to, so you can then query it with a between clause.

Each DML operations need to maintain that date range so it stays logically consistent (e.g. no overlaps, not gaps, no delete, etc).

At the end of the day, you should be able to query your data for any point in time consistently:

select  *
from    foo

join    bar
on      bar.bar_key = foo.bar_key

where   foo.foo_key = 1
and     julianday( ... ) between foo.valid_from and foo.valid_to
and     julianday( ... ) between bar.valid_from and bar.valid_to


Regarding (2), I would suggest to forgo traditional integrity constraint mechanisms (primary, unique, referential, etc) as they simply don't play well with (1). For example, one cannot express a meaningful, and useful, primary, nor unique key on versioned data. Ditto for referential constraints. Which also means you have to re-implement  all of the above by yourself. Which is a pain and rather error prone.

Got luck either ways. :)



_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: auto-incrementing integer in composite primary key

Petite Abeille-2
In reply to this post by Kit-18

On Apr 16, 2012, at 9:09 PM, Kit wrote:

> SELECT doc.record, t.rec FROM doc LEFT JOIN t ON doc.id=t.doc_id
>      WHERE doc.id=id_xx AND created_on<=time_xx
>      ORDER BY created_on DESC LIMIT 1;

- how do you represent deleted rows?
- how do you avoid version ambiguities (e.g. two rows created with the same timestamp)?


_______________________________________________
sqlite-users mailing list
[hidden email]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
12