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
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 anot
>
> 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 addres
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 tha
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
__
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
c
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 a
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 comman
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 to
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/
__
> 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 (
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 intr
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 t
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 to
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 possibl
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 assu
> 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 dat
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
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
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 unamb
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
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
22 matches
Mail list logo