如何修复损坏的ACCESS数据库文件

我就遇到过你的这种情况我在网上找了 N 久，如果没有备份的话就歇菜了。

希望你有备份的，下面的方法对你大概没什么作用了

被攻击后的数据库（asa或asp格式的）就算你把网站里的毒杀了后

把格式再改回来也没有用了

网上真的不安全啊

修复ACCESS数据库的几种常见方法:

技术支持部在日常工作中经常会碰到因非正常退出、网络不稳定或病毒等原因造成的Access数据库损坏。损坏了的Access数据库会造成软件运行不稳定，出现各种运行错误，为解决这类问题就必须对Access数据库进行修复。

修复Access数据库，我们一般使用微软Office 97中带的Access 97对数据库进行修复和整理。Access数据库被损坏分以下几种情况：1、严重损坏；2、轻度损坏；3、有些表被损坏或有些表的部分记录被损坏。下面就分情况介绍解决办法。

1、使用Access97打不开数据库、系统提示"不可识别的数据库格式"或"不是该表的索引"等信息，这样的数据库都是损坏比较严重的。损害严重的数据库一般来说都是无法修复的，只有恢复备份了，好在这种情况比较少见。

2、如果数据库损坏的不严重，只需要使用Access 97菜单上的“修复数据库”和“压缩数据库”就可以把数据库修复好。因为数据库轻微损坏的时候，一般也不会导致软件出什么问题，所以也不会引起人的注意，只有当数据库的某一个或几个表损坏了的时候，才会使软件变得不稳定，所以这种情况才是我们最常遇到的。

3、如何确定数据库中哪几个表有问题呢，我们首先利用Access 97建立一个空数据库，利用系统提供的“引入数据库”功能，选择目标数据库所有的表进行引入，Access 97当引入到有问题的表时系统会提示一些错误信息，把这个表的名字记下来以备以后修复时使用。

接下来利用Access97打开有问题的数据库，准备修复表。修复损坏的表的方法依照表损坏程度不同而不同，下面分情况介绍处理的办法：

一、表损坏的非常严重，表现为无法打开表，系统提示“Microsoft jet 找不到对象”、“没有读写权限”或“不可识别”等信息。

处理方法：这种表的已经损坏得非常严重了，一般无法修复。如果这个表不很重要或通常情况下表的内容为空的话，例如“常用凭证表”、“科目共享锁定表”或“凭证共享锁定表”，我们可以通过引入的方法把其他数据库的表引入，然后把有问题的表删除即可。

二、表中有几行内容非常混乱或字段内标有“#已删除”字样，但当要删除这些记录时就会出现错误信息不许删除。

处理办法：既然不让删除这些记录，我们可以通过使用SQL语句把没有问题的记录复制到一个新的表中，然后把老表删除把新表的名字改过来即可。例如“凭证及明细账表GL_ACCVOUCH”中有错误记录有无法删除，我们可以使用如下SQL语句把好的记录复制到GL_ACCTEMP中：

SELECT GL_ACCVOUCH.* INTO GL_ACCTEMP

FROM GL_ACCVOUCH WHERE {筛选的条件}

然后删除表GL_ACCVOUCH，再把表GL_ACCTEMP的名字改为GL_ACCVOUCH即可解决问题。

修复ACCESS数据库的注意事项，首先，我们在修复数据库前一定要做好备份，以防数据丢失或损坏；有一些数据库中有RELATION(关系)来维护数据的一致性，但当数据库异常后相关表的RELATION也就丢失了，在修复好数据库后一定要把RELATION再联好，有些软件可以自动修复RELATION,比如用友公司的ERP8.XX系列产品的数据库可以通过把表accinformation中的[cSysid]='AA' and [项目号]='99'的记录，把[设置值]和[缺省值]改为'8.0A0'，重新进入系统时，系统会自动升级并重建索引。

可以修复，从故障解析，数据库损坏分为逻辑层损坏和物理层损坏。

1，逻辑损坏是指，文件本身完整，系统表在逻辑结构上混乱造成的错误。

2，物理损坏是指，文件由于不完整，导致置疑等故障

数据库损坏，由断电，非法关机，系统重启，文件被误删除，误ghost自己恢复出来的文件附加失败，阵列崩溃等原因造成的。

逻辑层修复方法，网上有很多dbcc修复命令，可以区尝试下、

物理层还是找专业人员吧！

以下是参考资料,若无法解决,把数据发给我,我帮你看一下.一、SQL-Server附加数据库时失败。1、异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。2、异常分析：关于823错误的 SQL-SERVER 中的帮助：错误823严重级别 24消息正文在文件 "%4!" 的偏移量 %3! 处的 %2! 过程中，检测到 I/O 错误 %1!。解释Microsoft SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误 823 之前记录的其它核心消息应指出涉及了哪个设备。3、解决办法：在SQL-Server企业管理器中，新建同名数据库（这里假设为Test）后，停止数据库，把损坏的数据库文件Data.mdf和Test_log.LDF覆盖刚才新建数据库目录下的Data.mdf和Test_log.LDF，同时删除Test_log.LDF文件；启动数据库服务，发现数据库名Test后面有“置疑”字样。不要紧，打开SQL自带查询分析器，分别执行如下SQL语句：--第一、exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */--第二、update sysdatabases set status=32768 where name='数据库名' /* 设置数据库状态 */--第三、DBCC REBUILD_LOG ('数据库名','E:\database\1204_Log.LDF') /* 重建LDF文件 */--第四、update sysdatabases set status=0 where name='数据库名' /* 重置数据库状态 */--第五、restore database 数据库名 WITH RECOVERY /* 恢复数据库 */--第六、exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */按照此方法 *** 作，应该能修复数据库正常访问了。

---