无法读取数据库中所含的VBA工程怎么解决？

可能是以下7个原因引起的，要分不同情况具体对待

1、Office(Access)的补丁更新造成的

最近office2016版本 2019版本的很多都出现这个问题了 ，是因为Office(Access)的补丁更新造成的。微软的Access有几次补丁出现过这个bug, 解决办法是一是退回之前稳定的版本，二是更新到最最新的版本

一般 使用帐户-更新选项-立即更新 一下即可

2、如果是Office2010 ，看是否网友xc555这种情况，可参考他的解决方法

先安装office 2010 sp2补丁，再卸载office 2010 sp2补丁 重启就成功了

PS:在网上找了N个解答，一直无法解决，看到一篇文章（说：sp2补丁会将vb编译器升至7.1，虽未解决）但受启发，尝试先安装sp2补丁，再卸载，结果就成功了

3、是因为中英文系统变化引起

中文系统做的程序到英文系统会出现这个问题，换系统 或 在英文系统重新设计相关窗体，而且模块使用可能遇到问题。或者在出现这个提示后选取消，再 *** 作几次，就不再出现，对有问题的功能重新设计 （千万不要点确定）

4、VBA环境或版本改变导致的

将C:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\VBA目录中的文件恢复至安装状态，出现这个问题的原因是VBA程序被修改，必须恢复未被修改的版本。 只要把旧版路径为vba\vba7.1下的vbe7.dll文件拷贝替换到新安装的vba\vba7.1下替换就可以了 （先备份）

5、可能是VBA真正损坏了

可先备份当前数据库，再使用Access的压缩修复功能修复一下

6、还有可能是不同的版本混合交叉打开导致的（不兼容）

网友出现过：我的计算机上安装了Access 2010,并对前端Access文件的复制版本进行了一些更新。我重命名了更新的副本以替换原始访问文件,并将旧文件放在备份文件夹中。我需要在第二天进行另一次更新,但使用的VPN连接使访问前端文件成为一种痛苦,所以我远程进入一个承载该文件的服务器,并使用该服务器的Access 2007应用程序进行更新。文件版本是2007-2010,因此我不认为它会导致任何错误更新。但是,我不知道为什么。

在进行这些更新时,我从未更新过任何vba,也没有收到除了sql函数错误以外的任何类型的错误。每次都成功保存并压缩和修复前端。然后我的最终用户开始接收宏和vba错误,这些错误阻止他们打开文件或输入任何信息。我发现vba模块已从文件中完全删除。此外,每次使用Access 2010在自己的计算机上打开文件时,原始备份的每个备份和副本都会损坏,即使我没有单击“确定”继续删除VBA模块。如果没有收到vba错误,我无法打开单个文件。用户通过在Intranet站点上下载自己的副本来访问前端文件,这样就不会损坏实际的文件。当我尝试这样做时,文件仍然被损坏,甚至损坏了原始文件。我的同事能够找到一个干净的备份,最终用户能够恢复工作,但我不能触摸文件,否则它也会损坏。即使我使用shift+open跳过开始代码,我仍然会收到错误。我的同事正在运行Access 2013,在打开备份文件副本时未收到任何这些错误。

试过:

紧凑型维修

反编译/重新编译

Access 2010版本为14.0.7224.5000(32位),因此已下载Office 2010 SP2

反编译不起作用,因为打开文件时我会立即收到vba错误(shift+open)。我没有新的访问更新要下载。我不能恢复到以前的版本,因为这不是我的公司可以接受的解决方案。我没有尝试将对象导入新的前端文件,因为每次打开文件时,都会删除或损坏VBA模块,因此无法导入或导出它们。我会失去所有的vba模块,因为我不是最初的开发人员,我不知道包括什么。我正在尝试更新2013年的访问权限,但这可能需要一段时间。

我读到的关于这个问题的所有信息都表明,当不同版本的access尝试打开同一个文件时,会发生这种情况,但是如果我使用access 2007和2010打开的文件的版本是2007-2010,为什么我仍然会得到这个错误?如果这是2007年的问题,为什么我在使用2010年的同时还要损坏在使用2007年软件之前制作的每个备份文件,特别是如果其他人在使用2010年、2013年和2016年的时候能够很好地访问该文件?

7、如果还不行，尝试将所有对象导入到一个新数据库文件

希望可帮到您！，也可关注我

如果连接成功了，不能插入数据，肯定是你最后一句写错了。

mysqli_query($db,"INSERT INTO tablename(username,userpass) VALUES('$name','$pass')")

有几种可能：

列名写对象没有？

values()里的值的格式写对了没有？引号有没有加到？

我看你写的：('$name','$pass')")　如果是变量的话，是不能加单引号的，这样是读到不变量值的。

如果从库上表 t 数据与主库不一致，导致复制错误，整个库的数据量很大，重做从库很慢，如何单独恢复这张表的数据？通常认为是不能修复单表数据的，因为涉及到各表状态不一致的问题。下面就列举备份单表恢复到从库会面临的问题以及解决办法：

场景 1

如果复制报错后，没有使用跳过错误、复制过滤等方法修复主从复制。主库数据一直在更新，从库数据停滞在报错状态（假设 GTID 为 aaaa:1-100）。

修复步骤：

在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000）；

恢复到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:101，从库上表 t 的数据状态是领先其他表的。aaaa:101-10000 这些事务中只要有修改表 t 数据的事务，就会导致复制报错 ，比如主键冲突、记录不存在（而 aaaa:101 这个之前复制报错的事务必定是修改表 t 的事务）

解决办法：启动复制时跳过 aaaa:101-10000 这些事务中修改表 t 的事务。

正确的修复步骤：

1. 在主库上备份表 t （假设备份快照 GTID 为 aaaa:1-10000），恢复到从库；

2. 设置复制过滤，过滤表 t：

CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t')

3. 启动复制，回放到 aaaa:10000 时停止复制（此时从库上所有表的数据都在同一状态，是一致的）

START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000'

4. 删除复制过滤，正常启动复制。

注意事项：这里要用 mysqldump --single-transaction --master-data=2，记录备份快照对应的 GTID

场景 2

如果复制报错后，使用跳过错误、复制过滤等办法修复了主从复制。主、从库数据一直在更新。

修复步骤：

在主库上备份表 t （假设备份快照 GTID为 aaaa:1-10000）；

停止从库复制，GTID为 aaaa:1-20000；

恢复表 t 到从库；

启动复制。

这里的问题是复制起始位点是 aaaa:20001，aaaa:10000-20000 这些事务将不会在从库上回放，如果这里面有修改表 t 数据的事务，从库上将丢失这部分数据。

解决办法：从备份开始到启动复制，锁定表 t，保证 aaaa:10000-20000 中没有修改表 t 的事务。

正确修复步骤：

对表 t 加读锁；

在主库上备份表 t；

停止从库复制，恢复表 t；

启动复制；

解锁表 t。

如果是大表，这里可以用可传输表空间方式备份、恢复表，减少锁表时间。

---