Re: [sqlite] suggestion on the database design

John Machin wrote: > > On 21/08/2009 1:29 PM, pierr wrote: >> >> Simon Slavin-2 wrote: >>> >>> On 21 Aug 2009, at 3:26am, pierr wrote: >>> I did not know the sequence in defining the field matters. This is what I should have done. >>> Sorry, I should have explained better. You were

Re: [sqlite] suggestion on the database design

On 21/08/2009 1:29 PM, pierr wrote: > > Simon Slavin-2 wrote: >> >> On 21 Aug 2009, at 3:26am, pierr wrote: >> >>> I did not know the sequence in defining the field matters. This is >>> what I should have done. >> Sorry, I should have explained better. You were right: there is no >>

Re: [sqlite] suggestion on the database design

Simon Slavin-2 wrote: > > > On 21 Aug 2009, at 3:26am, pierr wrote: > >> I did not know the sequence in defining the field matters. This is >> what I should have done. > > Sorry, I should have explained better. You were right: there is no > difference. I was just rearranging the fields

Re: [sqlite] suggestion on the database design

On 21/08/2009 12:59 PM, Simon Slavin wrote: > On 21 Aug 2009, at 3:26am, pierr wrote: > >> I did not know the sequence in defining the field matters. This is >> what I should have done. > > Sorry, I should have explained better. You were right: there is no > difference. I was just

Re: [sqlite] suggestion on the database design

On 21 Aug 2009, at 3:26am, pierr wrote: > I did not know the sequence in defining the field matters. This is > what I should have done. Sorry, I should have explained better. You were right: there is no difference. I was just rearranging the fields in the classic way: with the primary key

Re: [sqlite] suggestion on the database design

Simon Slavin-2 wrote: > > If ts_start is an always increasing integer (i.e. no two records have > the same value) then I would see it as your primary key and as your > row id. In other words, your structure is more like > > CREATE TABLE IF NOT EXISTS tblIndex( > ts_start INTEGER

[sqlite] (no subject)

Hi guys, This is my first post. I am creating a simple document archiving program for small businesses. I am creating it in a scripting language called www.autohotkey.com. I intend to place the SQLite database file on a network share and use sqlite.dll to access and manipulate it. In general,

[sqlite] ANN: C#-SQLite 3.6.17

C#-SQLite has been updated to release 3.6.17 and is now ready for review. It currently runs 30992 tests with 0 errors, but still has issues with 4 tests. The project is located at http://code.google.com/p/csharp-sqlite/ Please keep in mind the following: * C#-SQLite is an independent

Re: [sqlite] Copying an open db file

Angus March wrote: > Igor Tandetnik wrote: >> Angus March wrote: >> >>> I want to copy a db file while it is still open, and I'm wondering >>> how safe that is. It would go something like this: >>> >>> 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE;

Re: [sqlite] Copying an open db file

2009/8/20 Angus March : > I want to copy a db file while it is still open, and I'm wondering how > safe that is. .dump -- Kit ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Linking all the column fields together (or something like this)

2009/8/20 ZB : > I need to search a table, which has - say - about 20 columns. Each column > should be checked against given string ("phrase"), in usual manner: > >  SELECT something FROM table WHERE col1 LIKE '%phrase%' OR col2 LIKE >  '%phrase%' OR col3 LIKE '%phrase%' ... OR

Re: [sqlite] Copying an open db file

Igor Tandetnik wrote: > Angus March wrote: > >> I want to copy a db file while it is still open, and I'm wondering how >> safe that is. It would go something like this: >> >> 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE; Many process >> are accessing the db

Re: [sqlite] Copying an open db file

Angus March wrote: > I want to copy a db file while it is still open, and I'm wondering how > safe that is. It would go something like this: > > 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE; Many process > are accessing the db afterall > 2. UPDATE a_table SET

[sqlite] Copying an open db file

I want to copy a db file while it is still open, and I'm wondering how safe that is. It would go something like this: 1. Lock exclusively with PRAGMA locking_mode=EXCLUSIVE; Many process are accessing the db afterall 2. UPDATE a_table SET a_column=0; 3. After finalizing (I'm using

[sqlite] Linking all the column fields together (or something like this)

I need to search a table, which has - say - about 20 columns. Each column should be checked against given string ("phrase"), in usual manner: SELECT something FROM table WHERE col1 LIKE '%phrase%' OR col2 LIKE '%phrase%' OR col3 LIKE '%phrase%' ... OR col20 LIKE '%phrase%' I'm afraid, it

Re: [sqlite] suggestion on the database design

On 20 Aug 2009, at 2:33pm, pierr wrote: > We have a database with a very simple schema: >CREATE TABLE IF NOT EXISTS tblIndex( > frame_type INT, > pts VARCHAR(5), > ts_start INT primary key, > ts_end INT) > > And the application scenario is : > 1. Every second usr will

Re: [sqlite] Problem with sqlite3_column_origin_name and AS Clause

"Igor Tandetnik" schrieb im Newsbeitrag news:h6bg82$td...@ger.gmane.org... > Dinu Scheppelmann (DAISY) wrote: > > Unfortunately when I get the column names by function > > sqlite3_column_origin_name(), the result columns have the names > > "DokId", "Name" and "Name" again -

Re: [sqlite] suggestion on the database design

On Thu, Aug 20, 2009 at 8:33 AM, pierr wrote: > > Hi, >  We have a database with a very simple schema: >    CREATE TABLE IF NOT EXISTS tblIndex( >     frame_type  INT, >     pts  VARCHAR(5), >     ts_start  INT primary key, >     ts_end  INT) > > And the application scenario

[sqlite] suggestion on the database design

Hi, We have a database with a very simple schema: CREATE TABLE IF NOT EXISTS tblIndex( frame_type INT, pts VARCHAR(5), ts_start INT primary key, ts_end INT) And the application scenario is : 1. Every second usr will insert 2 ~ 50 records ,and the ts_start fields of

[sqlite] Kevin Smekens is out of the office.

I will be out of the office starting 2009/08/20 and will not return until 2009/08/31. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] update - select

If you have synonym for rowid (i.e. column INTEGER PRIMARY KEY) or some other unique columns combination then you can do something like this: INSERT OR REPLACE INTO table_1 (rowid, field_a, field_b, field_c, field_d) SELECT table_1.rowid, table_2.field_a, table_2.field_b, table_2.field_c,

Re: [sqlite] update - select

On Thu, Aug 20, 2009 at 12:01 PM, Gerald Ebner wrote: > Dear all, > > it seems that sqlite does not allow update statements of this kind: > > UPDATE table_1 SET (field_a, field_b, field_c, field_d) = ( >    SELECT field_a, field_b, field_c, field_d FROM table_2 WHERE … > )

[sqlite] update - select

Dear all, it seems that sqlite does not allow update statements of this kind: UPDATE table_1 SET (field_a, field_b, field_c, field_d) = ( SELECT field_a, field_b, field_c, field_d FROM table_2 WHERE … ) WHERE I succeeded only with UPDATE table_1 SET field_a = (SELECT field_a FROM