> #1 WAL COMMIT will not corrupt current reading thread (even if deletes occur,
> changes/adds are not visible either).
> #2 Next SELECT transaction will pick up the new data.
> Correct?
Yes that's correct.
> Dangerous thing would be two threads writing if either one is using a currect
> SELECT
Soto clarify...this is a completely safe operation in 3.7.0.1.???
#1 WAL COMMIT will not corrupt current reading thread (even if deletes occur,
changes/adds are not visible either).
#2 Next SELECT transaction will pick up the new data.
Correct?
Dangerous thing would be two threads writing
> Which means the read works on old data until you COMMIT?
> Is that true? So that COMMIT will allow you to query the changed/new data
> from the other thread?
AFAIK, no. Of course until you COMMIT no reader will see your data.
But after you commit all already started reading transactions won't
Which means the read works on old data until you COMMIT?
Is that true? So that COMMIT will allow you to query the changed/new data from
the other thread?
Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Northrop Grumman Information Systems
Fr
> SQLite allows multiple readers, or exactly one wrier, accessing the database
> at the same time. You can't read and write simultaneously, you must arrange
> for your connections to take turns. SQLITE_BUSY error is a signal for you to
> back off, wait a little, then try again. See also
> http:
andres felipe tamayo cortes wrote:
> i have one application who reads a database, it run well without problems,
> but when i tried to load this dabase from other
> program (while its still running the first application), appearsme database
> blocked, isnt it possible to load one database from
>
6 matches
Mail list logo
