Yah, I tested in SQL*Plus - one window could see inserts, updates and
deletes that had been committed in another window (in which a commit or
rollback had not been issued). I ran the test again - delete data from a
table in one window and commit the change, and a select in the other
window disp
If you are NOT in autocommit mode, your connection (or the server, it
doesn't matter which) starts a transaction *when you issue your first
command*. Every command you issue on that connection is in that initial
transaction until you EXPLICITLY commit or rollback (or do something else
that comm
I believe you - I'm just a but surprised. I guess I had a singular view
of how a session should work based on Oracle. I would have expected that
until you execute SQL that requires a commit or a rollback, you wouldn't
be in a transaction. Unfortunately, if you have connections that are
read and
David Griffiths wrote:
"No, with the default transaction isolation level, REPEATABLE READ,
that's how it is supposed to work. You've started a transaction in
Window B, so Window B is immune to changes made in Window A until you
finish the transaction in Window B. See the manual for details
h
"No, with the default transaction isolation level, REPEATABLE READ,
that's how it is supposed to work. You've started a transaction in
Window B, so Window B is immune to changes made in Window A until you
finish the transaction in Window B. See the manual for details
http://dev.mysql.com/doc
On Wed, Aug 31, 2005 at 11:18:40PM -0400, Michael Stassen wrote:
> No, with the default transaction isolation level, REPEATABLE READ, that's
> how it is supposed to work. You've started a transaction in Window B, so
> Window B is immune to changes made in Window A until you finish the
> transac
David Griffiths wrote:
I just discovered some weird behaviour with MySQL 4.0 (4.0.24 and
4.0.18) using InnoDB.
If you have two connections to mysql (I use the mysql client), one of
which has autocommit turned on, an the other turned off, a row deleted
from the client with autocommit turned on
I just discovered some weird behaviour with MySQL 4.0 (4.0.24 and
4.0.18) using InnoDB.
If you have two connections to mysql (I use the mysql client), one of
which has autocommit turned on, an the other turned off, a row deleted
from the client with autocommit turned on still shows up in the c
