View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000807 | Database Workbench v4 | Microsoft SQL Server Module | public | 2014-02-12 16:59 | 2014-03-19 11:54 |
Reporter | Svein Erling Tysvær | Assigned To | Martijn Tonies | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
OS | Windows 7 Professional | OS Version | 6.1 Build7601SP1 | ||
Product Version | 4.4.4 | ||||
Fixed in Version | 4.4.5 | ||||
Summary | 0000807: Query prevents access | ||||
Description | After 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 Reproduce | Connect 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 Information | I'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. | ||||
Tags | No tags attached. | ||||
DBMS & Version | |||||
|
Could this be related to the transaction isolation you are using? MS SQL quickly issues locks on tables. |
|
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! |
|
Default isolation set to Read Committed, existing installs should modify this by hand. |
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 |