> > > > Not sure about the sqlite but that's not the case for Postgres or MsSQL > > (in the standard setup). Actual locks do not occur until the commit. > > And both now have savepoints. When you rollback to a savepoint, changes > > made since the savepoint are discarded but not the changes made before > > the savepoint. And I believe with Postgres you can imbed a transaction > > within a transaction (never used it). > > So other connections don't see the updates (INSERT, UPDATE, DELETE) until > the commit? That's correct for Postgres. Anything else would be a dirty read. Some setups require dirty reads such as banks. But MS SQL is different (it has no buffering). So MS SQL requires a dirty read and to avoid the lock you add "select * from table with (nolock) where ..."
That in a nut shell is why I like Postgres over other DB. > > I was under the impression that once a transaction was started, a SELECT on > "that data" would wait till the transaction was done so that the SELECT > would return 'current' data, where current includes changes made after the > transaction started. > > Maybe lock is the wrong term. blocking? > > Carl K Of course all that I am saying depends on transaction isolation settings. http://www.databasejournal.com/features/mssql/article.php/3530811 -- John Fabiani _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
