它已经被别的用户以独占方式打开，或没有查看数据的权限？

Question

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005' [Microsoft][ODBC Microsoft Access 驱动程序] Microsoft Jet 数据库引擎打不开文件'(未知的)'。 

Answer 1

这个错误产生的原因一般是同一条记录的读写产生了冲突，也就是说同时被操作，于是会造成死锁，认真检查你的代码吧。

当 Microsoft�0�3 SQL Server�6�4 遇到死锁时发生该错误。当两个（或多个）进程试图访问某个资源，而该资源上有另一个进程控制的锁时，发生死锁。因为每个进程都有对另一个资源的请求，所以各进程都不能完成。当检测到死锁时，SQL Server 将处理时间最少的命令回滚，并向客户端应用程序返回错误信息 1205。该错误不是严重错误，且不会导致批处理终止。
对策
在某些情况下，死锁条件将导致 DB-Library 函数（如 dbsqlexec、dbsqlok、dbresults 或 dbnextrow）返回 FAIL。程序应该始终检查从每个 DB-Library 函数返回的代码。如果这些 DB-Library 函数之一返回 FAIL，则程序应取消批处理并停止运行。在某些情况下，继续执行批处理中的后续函数是有可能的。但是，因为发生了死锁情况并且回滚了引起死锁的函数，所以批处理中的后续函数将可能因更严重的错误（如"没有找到对象"）而失败。
在其它情况下，死锁条件不会导致 DB-Library 函数返回 FAIL。在这些情况下，程序必须在消息处理程序中检查是否有错误信息 1205，并使用 dbsetuserdata 函数将此信息告知应用程序。然后程序必须在每个 DB-Library 调用之后检查是否有死锁指示符，如果检测到死锁则应取消批处理。
尽管在收到 1205 死锁消息后取消批处理可能似乎没有必要，但因为服务器并不总是终止死锁情况下的批处理，所以这确实必要。如果未取消批处理，则任何时候试图提交新的批处理时均将导致 DB-Library 错误 10038"结果挂起"。
还可以使用 SET DEADLOCK＿PRIORITY 语句（LOW 或 NORMAL）。SET DEADLOCK＿PRIORITY 控制在发生死锁情况时会话的反应方式。如果设置为 LOW，则进程将成为死锁情况下的首选牺牲品。如果设置为 NORMAL，则会话将使用默认的死锁处理方法。
如果死锁情况持续，则使用跟踪标记 1204 收集更多信息通常很有用。跟踪标记 1204 打印死锁链和牺牲品，如以下示例输出所示：
*** Deadlock Detected ***
==> Process 7 chosen as deadlock victim
== Deadlock Detected at: 1998-09-10 16:39:29.17
== Session participant information:
SPID: 7 ECID: 0 Statement Type: UPDATE
Input Buf: update t1 set c1 = c1 where c1 = 2
SPID: 8 ECID: 0 Statement Type: UPDATE
Input Buf: update t1 set c1 = c1 where c1 = 1

== Deadlock Lock participant information:
== Lock: KEY: 2:117575457:1 (010001000000)
Database: tempdb
Table: t1
Index: i1
- Held by: SPID 7 ECID 0 Mode "S"
- Requested by: SPID 8 ECID 0 Mode "X"
== Lock: KEY: 2:117575457:1 (020002000000)
Database: tempdb
Table: t1
Index: i1
- Held by: SPID 8 ECID 0 Mode "S"
- Requested by: SPID 7 ECID 0 Mode "X"
此死锁信息可以解释如下： 
第一部分显示死锁牺牲品、死锁时间以及死锁中涉及的会话。对于每个会话，显示当前的 SPID、语句类型和输入缓冲区的一部分。
第二部分显示有关死锁中涉及的锁的详细信息。从上面的输出，注意死锁涉及表 t1（索引 i1）上的键锁。死锁输出显示哪些进程拥有死锁中涉及的锁，哪些会话在等待锁被授权以及相关联的锁模式。
根据默认，生成最小日志量的进程将选作死锁牺牲品，并自动回滚。若要影响所回滚的会话，请为会话设置 DEADLOCK＿PRIORITY。
出现这个问题首先要考虑数据库设计的问题，检查会不会由于循环锁引起死锁的问题，即关系互相依赖；第二就要检查程序的问题，作为数据库sa我认为应该从这三方面来检查问题。
1、执行：
dbcc traceon (1204, 3605, -1)
go
dbcc tracestatus(-1)
go
目的是把锁信息写到日志上（../log/Errlog)文件上，以检查分析锁的产生；
2、设置lock_timeout变量的时间 
select @@lock_timeout (查询当前设置）
set lock_timeout 1800 (设置当前会话的当前锁超时设置，单位为毫秒）
这个应该和程序开发人员商量，嵌入在程序里。　（未做过，待测试：））
3、设置DEADLOCK_PRIORITY变量 
控制在发生死锁情况时会话的反应方式。