[EMAIL PROTECTED] wrote:
Gerry,
I took a look at this and I don't see how it works.
Sorry. I was just thinking about inserts.
Gerry
-
To unsubscribe, send email to [EMAIL PROTECTED]
I followed every one of these threads and it is really good stuff.
I've done some research to realize I need to do more.
I see that most of you are in the client/server world where you can ask
the client various questions about the query.
In my case, I am a standalone server embedded in a
Dennis Cote wrote:
Jef Driesen wrote:
I can give you the example of an application using sqlite as the on-disk
file format. As mentioned on the sqlite website [1], the traditional
File/Open operation does an sqlite3_open() and executes a BEGIN
TRANSACTION. File/Save does a COMMIT followed by
At 9:48 AM -0600 4/12/07, Dennis Cote wrote:
Yes I did assume no coupling because you didn't suggest any. If
there is coupling this is just another case of the second example.
While I didn't explicitly suggest coupling before, I was making my
arguments on the general case where actions
Gerry,
I took a look at this and I don't see how it works.
I believe I would have to do the following:
Make TEMP copies of all of the tables that are being modified.
Upon COMMIT:
Delete the old tables
Rename the temp tables to the old tables
COMMIT
I don't see an easy way to do
Thanks. I'll look into this path and see if it fits.
Anybody here live in the Irvine, Ca area.
After the discussions on this subject I have come to the conclusion that we
need somebody to implement our embedded database.
Ray
Gerry Snyder <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]
Autonomous transactions:
ie
begin
begin autonomous txn1
commit;
commit txn1
This transaction has no impact on the outer txn. I believe it can commit
either in or out of the parent transaction as well Quite a bit more
complicated
Darren Duncan wrote:
At 3:33 PM -0600 4/11/07, Dennis Cote wrote:
You have lost me here. If this transaction is considered successful
without executing the middle step (which is the same as executing it
and then undoing that execution) then that step does not belong in
this transaction.
Ken wrote:
Correct me if I'm wrong on this concept:
Adding nested transactions really means adding the ability to demark internally a transaction ID. So that later that transaction can be rolled back.
Consider
begin Main;
step a
savepoint
Ramon Ribó wrote:
I cannot agree here. Just imagine that the user decision is based on
the imported data.
Of course, you can read the data of the file, store in temporal
structures on memory, ask
the user and then, enter the data into the database. But the advantage
of using sqlite as
Dennis Cote <[EMAIL PROTECTED]> wrote: Ramon Ribó wrote:
>
>
> Imagine one application that can import data from a file. You want
> that, in case of computer crash, either all the data of the file is
> imported or none. At the same time, you want the user to manually
> accept or reject every
Jef Driesen wrote:
I can give you the example of an application using sqlite as the on-disk
file format. As mentioned on the sqlite website [1], the traditional
File/Open operation does an sqlite3_open() and executes a BEGIN
TRANSACTION. File/Save does a COMMIT followed by another BEGIN
Dennis,
I cannot agree here. Just imagine that the user decision is based on the
imported data.
Of course, you can read the data of the file, store in temporal structures
on memory, ask
the user and then, enter the data into the database. But the advantage of
using sqlite as
storage
Dennis Cote wrote:
[EMAIL PROTECTED] wrote:
It appears that my requirements are to be able to do the following:
BEGIN parent;
insert into t values ('a');
BEGIN child;
insert into t values ('b');
insert into t values ('c');
ROLLBACK child; // child aborts
insert
[EMAIL PROTECTED] wrote:
Here is an excerpt from my requirements doc:
If a transaction is aborted all database state is reset
("rolled-back") to its value at the time the transaction was opened.
Nested transactions abort or commit relative to their
parent transaction. In the case of an
At 3:33 PM -0600 4/11/07, Dennis Cote wrote:
You have lost me here. If this transaction is considered successful
without executing the middle step (which is the same as executing it
and then undoing that execution) then that step does not belong in
this transaction.
Instead of
begin
Ramon Ribó wrote:
Imagine one application that can import data from a file. You want
that, in case of computer crash, either all the data of the file is
imported or none. At the same time, you want the user to manually
accept or reject every section of the file.
This example can be
I forgot to mention that the stream data contains a BEGIN TRANSACTION and END
TRANSACTION marker.
Ray
[EMAIL PROTECTED] wrote:
> In my case, I am a slave device that must accept a stream of commands from an
> external device. I'm not sure if I can make intelligent decisions about
>
[EMAIL PROTECTED] wrote:
I'm not sure if I can make intelligent decisions about choosing what I commit
to the database.
Things don't look too bright for you or your users then. ;-)
I couldn't resist. :-)
Dennis Cote
Darren Duncan wrote:
While it is true in some cases that an application can be written to
know in advance whether certain SQL statements need to be run or not,
there are other cases where it can only easily know after having tried
it.
One type of situation that stands out the most to me is
In my case, I am a slave device that must accept a stream of commands from an
external device. I'm not sure if I can make intelligent decisions about
choosing what I commit to the database.
Ray
Darren Duncan <[EMAIL PROTECTED]> wrote:
> At 12:49 PM -0600 4/11/07, Dennis Cote wrote:
>
At 12:49 PM -0600 4/11/07, Dennis Cote wrote:
[EMAIL PROTECTED] wrote:
It appears that my requirements are to be able to do the following:
BEGIN parent;
insert into t values ('a');
BEGIN child;
insert into t values ('b');
insert into t values ('c');
ROLLBACK child;
[EMAIL PROTECTED] wrote:
It appears that my requirements are to be able to do the following:
BEGIN parent;
insert into t values ('a');
BEGIN child;
insert into t values ('b');
insert into t values ('c');
ROLLBACK child; // child aborts
insert into t values ('d');
It appears that my requirements are to be able to do the following:
BEGIN parent;
insert into t values ('a');
BEGIN child;
insert into t values ('b');
insert into t values ('c');
ROLLBACK child; // child aborts
insert into t values ('d');
COMMIT parent;
As a result
Darren Duncan <[EMAIL PROTECTED]> wrote:
The whole point of being implemented as separate transactions rather
than "save points" is that any particular block of code or SQL that
needs to be atomic doesn't have to special case how it is defined
depending on whether it is a main or child
Griggs, Donald
<[EMAIL PROTECTED]>
wrote:
Regarding: "...As Igor pointed out this does not resemble a full
implementation of transactions, as nested transactions can be
committed
and rolled back independently of the outer parent transaction."
Nonetheless, it would seem, just from the couple
At 12:33 PM -0400 4/9/07, Igor Tandetnik wrote:
Dennis Cote <[EMAIL PROTECTED]> wrote:
Darren Duncan wrote:
I will clarify that child transactions are just an elegant way of
partitioning a larger task, and that parent transactions always
overrule children; even if a child transaction commits
Dennis Cote <[EMAIL PROTECTED]> wrote:
Darren Duncan wrote:
I will clarify that child transactions are just an elegant way of
partitioning a larger task, and that parent transactions always
overrule children; even if a child transaction commits successfully,
a rollback of its parent means
28 matches
Mail list logo
