SQLite and transactional security

[Matthew Vanecek]

On Wed, 2003-09-10 at 10:07, Derek Atkins wrote:
> Hi,
> 
> I've forwarded this message to gnucash-devel.  Future messages
> of this ilk should be directed there.
> 
> -derek
> 
> drh at hwaci.com writes:
> 
> > I reviewing some discussion on the GnuCash mailing list
> > I noticed a misconception about SQLite that I wanted to
> > correct.
> > 
> > With SQLite, if your program crashes in the middle of an
> > update or if you turn off power in the middle of an update
> > or some other disaster happens in the middle of an update,
> > the database will be automatically rolled back to a
> > consistent state the next time it is opened.  I'm not sure
> > if this is what you mean by "transactional security" or
> > not.
> > 
> > To put it another way, updates to an SQLite database are
> > atomic.  Either the entire update occurs or none of it
> > occurs.  You never run into a situation where a program
> > crash causes an update to occur half-way.
> > 

That's a wonderful thing to know.  A question, though: does SQLite
support transactional updates (e.g., multiple updates rolled into one
BEGIN/COMMIT block)?

I could probably look at the docs, I suppose...
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20030910/e38dc347/attachment.pgp