Re: [sqlite] design question / discussion

Adolfo: I can't tell you how many times I felt a flat file approach would be better. However, 2 years ago when the design began there was a thought of 'Having the ability to mine data on the device would be an invaluable tool'. SQLite has proven superb for some aspects of the system, but not for

Re: [sqlite] design question / discussion

I've done an app like that before with a different db foundation. Basically 2 different databases, same structure. The logging app hits an ini file before each write, if the current db is different than the name in the ini file then close the current db, open the new db and write the row to the

Re: [sqlite] SQLite allows "RowID" to be the name of a column

Ralf Junker wrote: >> On a separate note, it is best for one to be able to name a table or column >> et al anything one wants, with all the choice of names as you can store in >> a text column for user data. Reserved words aren't an issue as long as >> entity names are referred to with an

Re: [sqlite] design question / discussion

Rich Rattanni wrote:>Hi I have a general design question. I have the following senario... >In an embedded system running linux 2.6.2x I have a sqlite database >constantly being updated with data acquired by the system. I cant >lose data (hence why I am using sqlite in the first place). However

Re: [sqlite] SQLite and Threadsafety (again)

I'm a bit curious why it wouldn't work. I use the same approach right here to have a exclusive access to a database table in the same model I told you. Also, I never used other locking mode that exclusive, because if want to write to the database the write lock should be granted exclusively by a

Re: [sqlite] design question / discussion

> It seems unclear to me what your requirements are trying to attempt. > > Do you need to keep any of this data, if so for how long? I have to keep all data until a download. Downloads can fail too so I cannot delete data until a download succeeds. > Do you need to be able to read the older

Re: [sqlite] SQLite and Threadsafety (again)

On May 21, 2008, at 12:08 PM, Shawn Wilsher wrote: > Hey all, > > I've come to the sad realization that we need to make our sqlite > wrapper threadsafe so it can be used on multiple threads without > consumers having to worry about threadsafety themselves. So, I wanted > to make sure all my

Re: [sqlite] SQLite and Threadsafety (again)

The problem with the approach you suggest as that that does not work when PRAGMA locking_mode = EXCLUSIVE, which we use in many places to improve performance. Additionally, it's my understanding that when using the shared cache, that transactions are grouped across connection objects (it's

Re: [sqlite] SQLite and Threadsafety (again)

Not to putting flame in question, but why not use any connection per thread ? At this way you can guarantee: - Correct transaction processing; - Avoid waiting on R/W locks, allowing more than one read to run concurrently; We also use this model with ODBC / ADO database layers. You don't need

Re: [sqlite] design question / discussion

I think your trying to overcome the read/write concurrency issue with sqlite correct? You want to have the ability to copy data (ie ftp) and recieve new data into an overflow database. Main.db = contains download.db and is an attachment point for ancillary db's. wrtdb_###.db = Always write

[sqlite] SQLite and Threadsafety (again)

Hey all, I've come to the sad realization that we need to make our sqlite wrapper threadsafe so it can be used on multiple threads without consumers having to worry about threadsafety themselves. So, I wanted to make sure all my assumptions about sqlite data structures are correct so I don't

Re: [sqlite] design question / discussion

> Perhaps i've missed something or don't understand it well. Your > databases is all on the same file or do you have 2 separate sqlite > sessions to 2 different databases files? In the first scenario you > must be very fast and in the second you can switch from one database > to the other, unbind

[sqlite] FW: do someone know? DotGnu

do some one know how i can conect from dotGnu to sqlite? i have mandriva i hope some one can helpmefromDavid Alejandro Garcia Garciathanks _ Juega y gana, tenemos 3 Xbox a la semana. http://club.prodigymsn.com/

Re: [sqlite] deleting 100,000 entries

Actually, I seem to recall a discussion that revealed that "DELETE FROM Foo" *does* truncate the table. The discussion came up because someone complained that "ON DELETE" triggers were not being fired; the explanation was that 'DELETE FROM Foo" simply drops and re-creates Foo. The solution was

Re: [sqlite] deleting 100,000 entries

The command "Delete from table" is optimized into a "drop table" then "Create table" pair. Effectively making the delete from table a "truncate". http://sqlite.org/lang_delete.html HTH, Ken Harold Wood & Meyuni Gani <[EMAIL PROTECTED]> wrote: Doesn't sqlite support the truncate table

[sqlite] SQLiteException: Unable to open the database file

Hi, I'm working on a vb.net application for PPC (Visual Studio 2008), with SQLite DB files and I have a problem on creating a master/detail form. I have created a dataset file (xsd) containg a single table. I also created a form containg a DataGrid, which is connected with the dataset through

Re: [sqlite] SQLite allows "RowID" to be the name of a column

Darren Duncan wrote: >I think the real problem here is that SQL allows you to have non-distinct >rows in a table, when all rows should be distinct. SQLite's implicit "RowID" does not allow non-distinct values (except for NULL, but this is documented behavior and only maintained for backwards

Re: [sqlite] SQLite allows "RowID" to be the name of a column

Federico Granata wrote: >have you seen here http://www.sqlite.org/autoinc.html ? Yes, I did. This documentation actually made me realize that the problem is not an implementation flaw but a design error, IMO. See my other answer in this thread for more rationale. Ralf

Re: [sqlite] SQLite allows "RowID" to be the name of a column

Ralf Junker wrote: > But thinking more about hijacking "RowID" I am glad this is now a separate > thread. Lack of a reseverd "RowID" column name to guarantee unambiguous record operations by general SQLite tools is a potential thread to data security IMO. I think the real problem here is

Re: [sqlite] SQLite allows "RowID" to be the name of a column

> > But thinking more about hijacking "RowID" I am glad this is now a separate > thread. Lack of a reseverd "RowID" column name to guarantee unambiguous > record operations by general SQLite tools is a potential thread to data > security IMO. > > I would very much appreciate if this could be

Re: [sqlite] SQLite allows "RowID" to be the name of a column

Bradley A. Town wrote: >Ralf Junker wrote: > >> This alerts me to a potential danger for SQLite managers which must rely on >> some means to retrieve THE RowID which uniquely identifies a record for >> in-grid table editing. If the "RowID" name can be hijacked by other columns >> and given

Re: [sqlite] design question / discussion

At 19:12 20/05/2008, you wrote: >Actually my reason for writing into a seperate database is more... >well crude. I tar several databases together then encrypt using >openSSL. Then an FTP like program transmits the data a central server. > I must suspend writing into the database for the duration

Re: [sqlite] deleting 100,000 entries

Doesn't sqlite support the truncate table command Woody from his pda -Original Message- From: Carlo S. Marcelo <[EMAIL PROTECTED]> Sent: Tuesday, May 20, 2008 8:49 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] deleting 100,000 entries