Scott,
Because of the issues that you have raised I realized that multiple
configuration commands rolled into one transaction is not a good idea and is
not necessary. The router will act on a single command from any CLI session.
As far as command action goes it will be connection less towards
Grr. Copy/paste error. The create statement was:
CREATE TABLE t (id INTEGER PRIMARY KEY AUTOINCREMENT, config TEXT);
On Thu, Apr 17, 2008 at 5:20 PM, Scott Hess <[EMAIL PROTECTED]> wrote:
> Just to be clear on "try it out", I mean something like the following,
> where A) is in one shell, and
Just to be clear on "try it out", I mean something like the following,
where A) is in one shell, and B) in another.
A) ...> ./sqlite3 test.db
A) sqlite> CREATE TABLE t (id INTEGER AUTOINCREMENT PRIMARY KEY NOT
NULL, config TEXT);
B) ...> ./sqlite3 test.db
B) sqlite> BEGIN;
A) sqlite> BEGIN;
A)
What will happen if you use BEGIN is that multiple users can get into
the configuration mode, but once one user gets past BEGIN and runs
anything which updates the database, the updates in other transactions
will start throwing SQLITE_LOCKED. Spin up two sqlite3 command-line
tools against the
Scott,
Every user will have thier own sqlite connection. So multiple users are
allowed for configuration. There will be one router connection to actually
act on the commited configurations. The router will act on
individual configuration rows. The router and the users interact with each
other
I am glad you asked. I am designing an interactive command line
interface to an ip router. A user will begin a transaction and start
configuring. At any time he can query for his configurations since the
begining of the transaction. When he is satisfied with his configuration he
will commit the
Yap I was wrong about triggers. Triggers are part of the same connection. So
I will try your suggestions. I will let you know how I made out. And thanks
so much for clearing my mistakes.
-Alex
On Thu, Apr 17, 2008 at 6:06 PM, Alex Katebi <[EMAIL PROTECTED]> wrote:
> I remember trying it before
I remember trying it before but I will try it again. Maybe I was wrong. I
will let you know.
Thanks!
On Thu, Apr 17, 2008 at 4:43 PM, Dennis Cote <[EMAIL PROTECTED]> wrote:
> Alex Katebi wrote:
> > But triggers don't trigger until commit.
> >
>
> That is not true.
>
> Trigger code executes
Alex Katebi wrote:
> But triggers don't trigger until commit.
>
That is not true.
Trigger code executes inline with the statement that caused the trigger
to fire.
Try a few triggers with the command line shell to convince yourself.
Dennis Cote
___
I don't mean in a separate database table - I mean in an in-memory
hashtable or array or something of the sort. Depending on what the
real goal you're trying to accomplish is, you might use triggers to
call custom function to accomplish this.
You presumably desire to get this information in the
Another approach could be to create an in-memory database (and in in-
memory table, like CREATE TABLE last_transaction(id INTEGER);)
and after each write operation save the rowid of the row using
sqlite3_last_insert_rowid (in C) or using SELECT last_insert_rowid();
(SQL) into that table.
---
The reason I did not keep track in a seperate table was because I wanted to
do it using triggers. But triggers don't trigger until commit.
On Thu, Apr 17, 2008 at 3:36 PM, Scott Hess <[EMAIL PROTECTED]> wrote:
> Until the data is committed, it's not really in the database. If you
> crash, it
Until the data is committed, it's not really in the database. If you
crash, it will be rolled back. So if it's really important to know
what data has been written to the database but not committed, why
don't you just track what you're writing to the database in an
in-memory data structure of
Hi Richard,
create table t1 (name);
insert into t1 values ('Alex');
begin;
insert into t1 values ('Richard');
select * from t1;
How can I select only the second row in the above example?
If there is not an easy way to do this I would probably have to use another
connection then diff the two
On Apr 17, 2008, at 2:35 PM, Alex Katebi wrote:
> Is there a way to select rows that have not been committed yet?
>
No. SQLite doesn't really commit rows. It commits pages. A
single page might hold multiple rows, only some of which might
have changed. Or a single row might span multiple
Is there a way to select rows that have not been committed yet?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
16 matches
Mail list logo
