View Issue Details

IDProjectCategoryView StatusLast Update
0000807Database Workbench v4Microsoft SQL Server Modulepublic2014-03-19 11:54
ReporterSvein Erling Tysvær Assigned ToMartijn Tonies  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
OSWindows 7 ProfessionalOS Version6.1 Build7601SP1 
Product Version4.4.4 
Fixed in Version4.4.5 
Summary0000807: Query prevents access
DescriptionAfter issuing a simple query through DBW (e.g. SELECT COUNT(*) FROM <table> WHERE <something>), other persons cannot update the same table, even after unpreparing the statement. Only upon closing the SQL Editor, the lock seems to clear.
Steps To ReproduceConnect to a Microsoft SQL Server database
Press F2
write random select query and run it
(optional: unprepare the statement)
Get some other user to update a record in a table involved in the query above
Additional InformationI'm using DBW through a VDI, it is possible that version 4.4.4 is the first where I've tried to access MS SQL Server through this VDI.
TagsNo tags attached.
DBMS & Version

Activities

Martijn Tonies

2014-02-12 17:37

administrator   ~0000262

Could this be related to the transaction isolation you are using?

MS SQL quickly issues locks on tables.

Svein Erling Tysvær

2014-02-13 11:36

reporter   ~0000263

You're right, Martijn, changing from repeatable read to read committed fixed my immediate problem.

Two things to note though (albeit not a major issue anymore):
1) Searching the internet indicates that read committed is the default behaviour of SQL Server, whereas I think Database Workbench uses repeatable read as the default (I'm almost certain I've never changed this before). Hence, I think that at least for fresh installations (not necessarily upgrades), DBW ought to use read committed as default.

2) (if repeatable read) The lock is kept until closing the sql editor, even when the statement is unprepared and the commit/rollback buttons are disabled (possibly due to the query simply being a COUNT). With repeatable read, I think the commit/rollback buttons ought to be active until locks are released.

Thanks for helping me out!

Martijn Tonies

2014-03-11 15:30

administrator   ~0000266

Default isolation set to Read Committed, existing installs should modify this by hand.

Issue History

Date Modified Username Field Change
2014-02-12 16:59 Svein Erling Tysvær New Issue
2014-02-12 17:37 Martijn Tonies Note Added: 0000262
2014-02-12 17:37 Martijn Tonies Assigned To => Martijn Tonies
2014-02-12 17:37 Martijn Tonies Status new => feedback
2014-02-13 11:36 Svein Erling Tysvær Note Added: 0000263
2014-02-13 11:36 Svein Erling Tysvær Status feedback => assigned
2014-03-11 15:30 Martijn Tonies Note Added: 0000266
2014-03-11 15:30 Martijn Tonies Status assigned => resolved
2014-03-11 15:30 Martijn Tonies Fixed in Version => 4.4.5
2014-03-11 15:30 Martijn Tonies Resolution open => fixed
2014-03-19 11:54 Martijn Tonies Status resolved => closed