From ab-mi at post3.tele.dk Thu Jun 20 17:58:55 2013 From: ab-mi at post3.tele.dk (Asger Blond) Date: Fri, 21 Jun 2013 00:58:55 +0200 Subject: [dba-SQLServer] Schema names and security boundaries - second try... In-Reply-To: References: <2BF399FD17294D1983F5311563B88A88@abpc> Message-ID: Hi all, Some weeks ago I posted a question about your usage of schema names but didn't get any response. I'll try once more: ----- How do you use schema names in SQL Server if you want to use them as meaningful namespaces, and also intent to use them as security boundaries but don't want to grant permissions on the base tables to any other than admins? Some background: As you probably know Microsoft made an important change in SQL Server 2005 separating schema names and owner names. Prior to 2005 the schema name of an object always identified the owner of the object. For example an object named JohnDoe.Customer would imply that the owner of the object was a user named JohnDoe. You couldn't have an object with a more meaningful name prefix such as Sales.Customer unless you had a user named Sales, who would then be the owner of the object. Quite an awkward situation which for ages led to schema names not being used as intentional by the SQL standard: an identifier of meaningful groupings, i.e. of "namespaces". The net effect of SQL Server not conforming to the SQL standard was that objects most often wasn't identified by a meaningful namespace names but was just prefixed by dbo, implying that the object was owned by the standard database owner user dbo. IMO it's good practice to have all objects owned by the build-in standard database owner user named dbo. But IMO it's really bad practice to junk all objects into the same namespace. Fortunately Microsoft changed its practice in 2005 and brought the usage of object prefixes in accordance with standard SQL. From 2005 and onwards the prefix doesn't imply any ownership. You can now have an object named JohnDoe.Customer which is actually owned by DonaldJones (but normaly I would prefer to have it owned by the standard user dbo). And you can have an object named Sales.Customer which is actually not owned by a user named Sales but by a user named DonaldJones (but again normally I would prefer to have it owned by the standard user dbo). So far so good. But there's more to it: Security. Schema names can be used as security boundaries: If you grant a permission on a schema to a user or role you are granting this permission on each and every objects in the schema. Quite effective... But a NO GO if you are member of the school saying "Don't ever grant missions to tables, only grant permissions on programming objects accessing the tables (such as views, stored procedures, and functions)". I belong to this school. So - to repeat my question: How do you use schema names in SQL Server if you want to use them as meaningful namespaces, and also intent to use them as security boundaries but don't want to grant permissions on the base tables to any other than admins? My practice is: Create separate schemas for tables and user-accessible objects within each meaningful grouping of the objects. For example: Table Customer: Sales_Table.Customer (for the table and only accessible for admins) Sales.CustomerView (for a user accessible view on the Sales_Table.Customer table) Sales.CustomerProcedure (for a user accessible procedure on the Sales_Table.Customer table) Sales.CustomerFunction (for a user accessible function on the Sales_Table.Customer table) Note this is not about naming conventions - whether to use prefixes such as vw for views, usp for procedures, and udf for functions. That's a different discussion. Here I'm only applying the names CustomerView etc. as placeholders for user accessible objects. My question is about separating user accessible object from tables using schema names. Curious to hear your thoughts on best practices. / Asger _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Fri Jun 21 03:21:09 2013 From: marklbreen at gmail.com (Mark Breen) Date: Fri, 21 Jun 2013 09:21:09 +0100 Subject: [dba-SQLServer] Schema names and security boundaries - second try... In-Reply-To: References: <2BF399FD17294D1983F5311563B88A88@abpc> Message-ID: Hello Asger, enjoyable email, thank you for posting in such detail. I have little to add, other than to tell of my experience. 1) in the last 15 years, I have never broken down SQL server security on an object basis. Perhaps most of my app are smaller and the average user is entitled to access to most of the objects. I can imagine in a large system with hundreds of tables and tens of groups of functionality that such granular permissions are required. 2) in recent years, with a web front end, I have a few times recalled the object level permissions we read about in the past and wondered is that all gone away. Most web apps I have been have one connection string. 3) I know I should split permissions so that users cannot access the raw tables, but honestly, I rarely do. Finally, in one app I developed a few years ago, I used a different scheme than dbo. It proved for me to be a PITA, especially when I sometimes see the tables in SSMS and sometimes though RedGate. Nowadays, I only use one or two characters to cause my tables to sort based in name, eg, dbo.AD_Customers, dbo.AD_Orders. My main curiosity is should we all be apply these high levels of quality that you are writing about? It adds some complexity and overhead to a project. It is the way we should be working in the smaller apps we develop? And finally, when we develop on web app, with many roles, is there any practical to avail of SQL Server object based security? On 20 June 2013 23:58, Asger Blond wrote: > Hi all, > > Some weeks ago I posted a question about your usage of schema names but > didn't get any response. > I'll try once more: > > ----- > > How do you use schema names in SQL Server if you want to use them as > meaningful namespaces, and also intent to use them as security boundaries > but don't want to grant permissions on the base tables to any other than > admins? > > > Some background: > As you probably know Microsoft made an important change in SQL Server 2005 > separating schema names and owner names. > Prior to 2005 the schema name of an object always identified the owner of > the object. For example an object named JohnDoe.Customer would imply that > the owner of the object was a user named JohnDoe. You couldn't have an > object with a more meaningful name prefix such as Sales.Customer unless you > had a user named Sales, who would then be the owner of the object. > Quite an awkward situation which for ages led to schema names not being > used as intentional by the SQL standard: an identifier of meaningful > groupings, i.e. of "namespaces". The net effect of SQL Server not > conforming to the SQL standard was that objects most often wasn't > identified by a meaningful namespace names but was just prefixed by dbo, > implying that the object was owned by the standard database owner user dbo. > IMO it's good practice to have all objects owned by the build-in standard > database owner user named dbo. But IMO it's really bad practice to junk all > objects into the same namespace. > Fortunately Microsoft changed its practice in 2005 and brought the usage > of object prefixes in accordance with standard SQL. From 2005 and onwards > the prefix doesn't imply any ownership. You can now have an object named > JohnDoe.Customer which is actually owned by DonaldJones (but normaly I > would prefer to have it owned by the standard user dbo). And you can have > an object named Sales.Customer which is actually not owned by a user named > Sales but by a user named DonaldJones (but again normally I would prefer to > have it owned by the standard user dbo). > So far so good. But there's more to it: Security. > Schema names can be used as security boundaries: If you grant a permission > on a schema to a user or role you are granting this permission on each and > every objects in the schema. Quite effective... > But a NO GO if you are member of the school saying "Don't ever grant > missions to tables, only grant permissions on programming objects accessing > the tables (such as views, stored procedures, and functions)". I belong to > this school. > So - to repeat my question: How do you use schema names in SQL Server if > you want to use them as meaningful namespaces, and also intent to use them > as security boundaries but don't want to grant permissions on the base > tables to any other than admins? > > My practice is: Create separate schemas for tables and user-accessible > objects within each meaningful grouping of the objects. For example: > Table Customer: > > Sales_Table.Customer (for the table and only accessible for admins) > > Sales.CustomerView (for a user accessible view on the Sales_Table.Customer > table) > > Sales.CustomerProcedure (for a user accessible procedure on the > Sales_Table.Customer table) > > Sales.CustomerFunction (for a user accessible function on the > Sales_Table.Customer table) > > Note this is not about naming conventions - whether to use prefixes such > as vw for views, usp for procedures, and udf for functions. That's a > different discussion. Here I'm only applying the names CustomerView etc. as > placeholders for user accessible objects. > My question is about separating user accessible object from tables using > schema names. > > Curious to hear your thoughts on best practices. > > / Asger > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From fuller.artful at gmail.com Thu Jun 20 05:26:12 2013 From: fuller.artful at gmail.com (Arthur Fuller) Date: Thu, 20 Jun 2013 06:26:12 -0400 Subject: [dba-SQLServer] Microsoft unleashes bug bounty program Message-ID: Microsoft's new bounty program aims to nail security holes, bugs and vulnerabilities even before the products are released (i.e. betas are covered as well as released versions). See ZDNet for the full story. -- Arthur Cell: 647.710.1314 Prediction is difficult, especially of the future. -- Niels Bohr From gustav at cactus.dk Fri Jun 21 09:28:28 2013 From: gustav at cactus.dk (Gustav Brock) Date: Fri, 21 Jun 2013 16:28:28 +0200 Subject: [dba-SQLServer] [Cross-Posted to VB and SQL] elapsed time in ASP.Net Message-ID: <013f01ce6e8b$98e9ed20$cabdc760$@cactus.dk> Hi Jeff I'm not into VB.NET but in C# you have a TimeSpan data type which you get by subtracting in-time from out-time. Then you can format this as you like to, say, h:mm. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Jeff B Sendt: 30. august 2012 21:48 Til: dba-VB; Dba-SQL Emne: [dba-SQLServer] [Cross-Posted to VB and SQL] elapsed time in ASP.Net Hello ALL! I am trying to determine the elapsed time on an ASP.net site. I am using VB.net for coding and SQL Server 2008 Time (7) data type for the time values. I am using a button to record a time in and a second button to record time out. What I would like to do is create a third button that would allow the users to click the button and see the elapsed time. I also want to store this value as a Time (7) data type. I have found numerous examples using datediff, but none of them seem to be working for me. Has anybody here tried this? Can someone help point me in the right direction? Thanks in Advance for ANY help! Jeff Barrows MCP, MCAD, MCSD Outbak Technologies, LLC Racine, WI jeff.developer at gmail.com From ab-mi at post3.tele.dk Fri Jun 21 14:45:46 2013 From: ab-mi at post3.tele.dk (Asger Blond) Date: Fri, 21 Jun 2013 21:45:46 +0200 Subject: [dba-SQLServer] Schema names and security boundaries - second try... In-Reply-To: References: <2BF399FD17294D1983F5311563B88A88@abpc> Message-ID: <474FA37622504DFC81C6FD4BB7EE57B9@abpc> Hi Mark, Thanks for our reply. My reasons for exposing data to applications only through abstraction layer objects (like views, procedures, functions, triggers) and to avoid exposing tables are well covered by this video: http://www.youtube.com/watch?v=OQEwua8u2mc The video focuses on two main reasons for using abstraction layer objects: security and shielding of applications from design changes to tables. One more reason I would like to mention is performance. Abstraction layer objects make more efficient use of query plan caching than adhoc queries against tables do. SQL Server caches plans for all kinds of queries, even for the most trivial adhoc query. But these kinds of plans will only be reused if the wording of a new query *exactly* matches the wording of the cached query: tiny changes like a different case for identifiers or keywords will result in a new plan - i.e. "select * from dbo.Customers" is not equal to "Select * from dbo.Customers" or "select * from dbo.customers", and will disable plan reuse. In contrast an abstraction layer object like a view, procedure, or function will maintain wording and therefore more likely ensure plan reuse. This being so there seems to be a need to separate schemas for tables from schemas for abstraction layer objects - especially if you want to grant permissions on the schema level, which for me is quite convenient. / Asger -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Mark Breen Sendt: 21. juni 2013 10:21 Til: Discussion concerning MS SQL Server Emne: Re: [dba-SQLServer] Schema names and security boundaries - secondtry... Hello Asger, enjoyable email, thank you for posting in such detail. I have little to add, other than to tell of my experience. 1) in the last 15 years, I have never broken down SQL server security on an object basis. Perhaps most of my app are smaller and the average user is entitled to access to most of the objects. I can imagine in a large system with hundreds of tables and tens of groups of functionality that such granular permissions are required. 2) in recent years, with a web front end, I have a few times recalled the object level permissions we read about in the past and wondered is that all gone away. Most web apps I have been have one connection string. 3) I know I should split permissions so that users cannot access the raw tables, but honestly, I rarely do. Finally, in one app I developed a few years ago, I used a different scheme than dbo. It proved for me to be a PITA, especially when I sometimes see the tables in SSMS and sometimes though RedGate. Nowadays, I only use one or two characters to cause my tables to sort based in name, eg, dbo.AD_Customers, dbo.AD_Orders. My main curiosity is should we all be apply these high levels of quality that you are writing about? It adds some complexity and overhead to a project. It is the way we should be working in the smaller apps we develop? And finally, when we develop on web app, with many roles, is there any practical to avail of SQL Server object based security? On 20 June 2013 23:58, Asger Blond wrote: > Hi all, > > Some weeks ago I posted a question about your usage of schema names but > didn't get any response. > I'll try once more: > > ----- > > How do you use schema names in SQL Server if you want to use them as > meaningful namespaces, and also intent to use them as security boundaries > but don't want to grant permissions on the base tables to any other than > admins? > > > Some background: > As you probably know Microsoft made an important change in SQL Server 2005 > separating schema names and owner names. > Prior to 2005 the schema name of an object always identified the owner of > the object. For example an object named JohnDoe.Customer would imply that > the owner of the object was a user named JohnDoe. You couldn't have an > object with a more meaningful name prefix such as Sales.Customer unless you > had a user named Sales, who would then be the owner of the object. > Quite an awkward situation which for ages led to schema names not being > used as intentional by the SQL standard: an identifier of meaningful > groupings, i.e. of "namespaces". The net effect of SQL Server not > conforming to the SQL standard was that objects most often wasn't > identified by a meaningful namespace names but was just prefixed by dbo, > implying that the object was owned by the standard database owner user dbo. > IMO it's good practice to have all objects owned by the build-in standard > database owner user named dbo. But IMO it's really bad practice to junk all > objects into the same namespace. > Fortunately Microsoft changed its practice in 2005 and brought the usage > of object prefixes in accordance with standard SQL. From 2005 and onwards > the prefix doesn't imply any ownership. You can now have an object named > JohnDoe.Customer which is actually owned by DonaldJones (but normaly I > would prefer to have it owned by the standard user dbo). And you can have > an object named Sales.Customer which is actually not owned by a user named > Sales but by a user named DonaldJones (but again normally I would prefer to > have it owned by the standard user dbo). > So far so good. But there's more to it: Security. > Schema names can be used as security boundaries: If you grant a permission > on a schema to a user or role you are granting this permission on each and > every objects in the schema. Quite effective... > But a NO GO if you are member of the school saying "Don't ever grant > missions to tables, only grant permissions on programming objects accessing > the tables (such as views, stored procedures, and functions)". I belong to > this school. > So - to repeat my question: How do you use schema names in SQL Server if > you want to use them as meaningful namespaces, and also intent to use them > as security boundaries but don't want to grant permissions on the base > tables to any other than admins? > > My practice is: Create separate schemas for tables and user-accessible > objects within each meaningful grouping of the objects. For example: > Table Customer: > > Sales_Table.Customer (for the table and only accessible for admins) > > Sales.CustomerView (for a user accessible view on the Sales_Table.Customer > table) > > Sales.CustomerProcedure (for a user accessible procedure on the > Sales_Table.Customer table) > > Sales.CustomerFunction (for a user accessible function on the > Sales_Table.Customer table) > > Note this is not about naming conventions - whether to use prefixes such > as vw for views, usp for procedures, and udf for functions. That's a > different discussion. Here I'm only applying the names CustomerView etc. as > placeholders for user accessible objects. > My question is about separating user accessible object from tables using > schema names. > > Curious to hear your thoughts on best practices. > > / Asger > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From Gustav at cactus.dk Sat Jun 29 03:57:47 2013 From: Gustav at cactus.dk (Gustav Brock) Date: Sat, 29 Jun 2013 10:57:47 +0200 Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans Message-ID: Hi all A table didn't respond at the client's SQL Server. The dba told that it was locked by a uncomitted transaction, and a restart of the SQL Server was needed. That happened and the table was accessible again. This table, however, is only used by an Access app via ODBC, and nowhere is BeginTrans used for the table. As to my understanding, SQL Server performs AutoCommit if not told otherwise. So, questions: 1. How can a BeginTrans be applied without a RollBack/CommitTrans? 2. Is it really necessary to restart the SQL Server to unlock the table? Any other suggestions what to look for or how to prevent this situation? /gustav From jlawrenc1 at shaw.ca Sat Jun 29 10:40:14 2013 From: jlawrenc1 at shaw.ca (Jim Lawrence) Date: Sat, 29 Jun 2013 08:40:14 -0700 Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans In-Reply-To: References: Message-ID: Hi Gustav: Question: Why would a BeginTrans be executed without the follow up of a RollBack/CommitTrans? This probably is what is locking the table. I am no expert in ODBC, as I only ever use ADO, it is faster and has never failed in almost 20 years. Example: Dim objConn As ADODB.Connection Dim objCmd As ADODB.Command Set objConn = New ADODB.Connection Set objCmd = New ADODB.Command objConn.Open gstrConnectionString objConn.BeginTrans With objCmd .ActiveConnection = objConn .CommandType = adCmdStoredProc .CommandText = "StoredProcedureName1" .Parameters.Append .CreateParameter("@intCode1", adInteger, adParamInput, , lngCode2) End With objCmd.Execute objConn.CommitTrans ... Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Saturday, June 29, 2013 1:58 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans Hi all A table didn't respond at the client's SQL Server. The dba told that it was locked by a uncomitted transaction, and a restart of the SQL Server was needed. That happened and the table was accessible again. This table, however, is only used by an Access app via ODBC, and nowhere is BeginTrans used for the table. As to my understanding, SQL Server performs AutoCommit if not told otherwise. So, questions: 1. How can a BeginTrans be applied without a RollBack/CommitTrans? 2. Is it really necessary to restart the SQL Server to unlock the table? Any other suggestions what to look for or how to prevent this situation? /gustav _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From Gustav at cactus.dk Sat Jun 29 11:11:23 2013 From: Gustav at cactus.dk (Gustav Brock) Date: Sat, 29 Jun 2013 18:11:23 +0200 Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans Message-ID: Hi Jim Thanks, but this is DAO with "normal" select and action queries and some pass-through queries for special tasks, no stored procedures. /gustav >>> jlawrenc1 at shaw.ca 29-06-13 17:40 >>> Hi Gustav: Question: Why would a BeginTrans be executed without the follow up of a RollBack/CommitTrans? This probably is what is locking the table. I am no expert in ODBC, as I only ever use ADO, it is faster and has never failed in almost 20 years. Example: Dim objConn As ADODB.Connection Dim objCmd As ADODB.Command Set objConn = New ADODB.Connection Set objCmd = New ADODB.Command objConn.Open gstrConnectionString objConn.BeginTrans With objCmd .ActiveConnection = objConn .CommandType = adCmdStoredProc .CommandText = "StoredProcedureName1" .Parameters.Append .CreateParameter("@intCode1", adInteger, adParamInput, , lngCode2) End With objCmd.Execute objConn.CommitTrans ... Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Saturday, June 29, 2013 1:58 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans Hi all A table didn't respond at the client's SQL Server. The dba told that it was locked by a uncomitted transaction, and a restart of the SQL Server was needed. That happened and the table was accessible again. This table, however, is only used by an Access app via ODBC, and nowhere is BeginTrans used for the table. As to my understanding, SQL Server performs AutoCommit if not told otherwise. So, questions: 1. How can a BeginTrans be applied without a RollBack/CommitTrans? 2. Is it really necessary to restart the SQL Server to unlock the table? Any other suggestions what to look for or how to prevent this situation? /gustav From fhtapia at gmail.com Sat Jun 29 11:47:07 2013 From: fhtapia at gmail.com (Francisco Tapia) Date: Sat, 29 Jun 2013 09:47:07 -0700 Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans In-Reply-To: References: Message-ID: Gustav, Yes you can kick off a Begin Trans w/o ever writing in a rollback or commit in your execution, if you perform the action using the query analyzer (management studio interface), the ide will catch that and give you an error (normally). otherwise, a lost thread can lock the table indefinitely. a solution would be to kick off a kill of the session id on the server. this usually auto-kicks in a rollback. the other method is to send in a commit or rollback command using the same session from your application. I haven't used ODBC in a really long time, but a time out on this protocol should be respected by the server and auto-kickin a rollback, since you are using Access that would be my expectation. What is your environment? OS, application, server edition version etc..? -Francisco -------------------------- You should follow me on twitter here Blogs: SqlThis! | XCodeThis! -------------------------- Save on your mobile wireless here On Sat, Jun 29, 2013 at 1:57 AM, Gustav Brock wrote: > Hi all > > A table didn't respond at the client's SQL Server. > The dba told that it was locked by a uncomitted transaction, and a restart > of the SQL Server was needed. That happened and the table was accessible > again. > > This table, however, is only used by an Access app via ODBC, and nowhere > is BeginTrans used for the table. As to my understanding, SQL Server > performs AutoCommit if not told otherwise. > > So, questions: > > 1. How can a BeginTrans be applied without a RollBack/CommitTrans? > 2. Is it really necessary to restart the SQL Server to unlock the table? > > Any other suggestions what to look for or how to prevent this situation? > > /gustav > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From Gustav at cactus.dk Sat Jun 29 16:10:46 2013 From: Gustav at cactus.dk (Gustav Brock) Date: Sat, 29 Jun 2013 23:10:46 +0200 Subject: [dba-SQLServer] Table lock with uncommitted BeginTrans Message-ID: Hi Francisco Server info is: Microsoft SQL Server Enterprise Edition Microsoft Windows NT 5.2 (3790) NT INTEL X86 10.0.4000.0 Client info is: Access 2010, 32-bit, latest SPs and updates Windows 7, 64-bit, latest SPs and updates I know you can call a BeginTrans and - by error - leave it uncommitted, but we have refrained from using transactions because the app doesn't perform large scale operations on the tables; it performs mostly lookup and record-by-record updates and additions. We can, however, have concurrency issues, but it is my understanding that in such cases the autocommit will fail and the changes will be rolled back automatically. /gustav >>> fhtapia at gmail.com 29-06-13 18:47 >>> Gustav, Yes you can kick off a Begin Trans w/o ever writing in a rollback or commit in your execution, if you perform the action using the query analyzer (management studio interface), the ide will catch that and give you an error (normally). otherwise, a lost thread can lock the table indefinitely. a solution would be to kick off a kill of the session id on the server. this usually auto-kicks in a rollback. the other method is to send in a commit or rollback command using the same session from your application. I haven't used ODBC in a really long time, but a time out on this protocol should be respected by the server and auto-kickin a rollback, since you are using Access that would be my expectation. What is your environment? OS, application, server edition version etc..? -Francisco -------------------------- You should follow me on twitter here Blogs: SqlThis! | XCodeThis! -------------------------- Save on your mobile wireless here On Sat, Jun 29, 2013 at 1:57 AM, Gustav Brock wrote: > Hi all > > A table didn't respond at the client's SQL Server. > The dba told that it was locked by a uncomitted transaction, and a restart > of the SQL Server was needed. That happened and the table was accessible > again. > > This table, however, is only used by an Access app via ODBC, and nowhere > is BeginTrans used for the table. As to my understanding, SQL Server > performs AutoCommit if not told otherwise. > > So, questions: > > 1. How can a BeginTrans be applied without a RollBack/CommitTrans? > 2. Is it really necessary to restart the SQL Server to unlock the table? > > Any other suggestions what to look for or how to prevent this situation? > > /gustav