Re: [sqlite] proposal for write-lock on "commit" rather than "begin transaction"

On 25/10/62 23:07, Brannon King wrote: This is a request for a small change to the handling of multiple connections. I think it would significantly enhance the usefulness there via allowing multiple "views" of the data. Consider that I have two simultaneous connections to one file, named Con1

Re: [sqlite] proposal for write-lock on "commit" rather than "begin transaction"

On Sat, 26 Oct 2019 at 00:07, Brannon King wrote: > This is a request for a small change to the handling of multiple > connections. I think it would significantly enhance the usefulness there > via allowing multiple "views" of the data. > > Consider that I have two simultaneous connections to

Re: [sqlite] proposal for write-lock on "commit" rather than "begin transaction"

> > Two users – members of staff – enter data. Each user enters a new > invoice. One of these entries gets rolled back. What should their > software do ? Or should it just return an error message to the user ? > Multi-user data entry is not a part of my intended use case. I think other

Re: [sqlite] proposal for write-lock on "commit" rather than "begin transaction"

On 25 Oct 2019, at 5:07pm, Brannon King wrote: > Once one connection commits, the other connection will no longer be allowed > to commit. It will be forced to rollback (or perhaps rebase if there are no > conflicts). While lots of software supports rollback, in that it issues an error message

[sqlite] proposal for write-lock on "commit" rather than "begin transaction"

This is a request for a small change to the handling of multiple connections. I think it would significantly enhance the usefulness there via allowing multiple "views" of the data. Consider that I have two simultaneous connections to one file, named Con1 and Con2. They could be in one process or