使用Excel作为Access数据库的前端（使用VBA）
我正在为朋友构build一个小应用程序，他们希望能够使用Excel作为前端。 （UI基本上是Excel中的用户表单）。 他们有一堆Excel中的数据，他们希望能够查询，但我不想用Excel作为数据库，因为我不认为它适合于这个目的，并且正在考虑使用Access。 [顺便说一句，我知道Access有它的缺点，但在朋友的PC上已经有可用的零预算和Access]
总之，我正在考虑将一堆数据转储到Access中，然后使用Excel作为前端查询数据库并在用户窗体样式环境中显示结果。
问题：
- 使用ADO / DAO从Excel中链接到Access是多么容易？ 在function方面是相当有限的，还是我可以创造性？
- 我是否支付性能损失（使用Access中的表单作为UI）？
- 假设数据库将始终使用Excel VBA中的ADO / DAO命令进行更新，这是否意味着我可以让多个Excel用户使用该单个Access数据库，而不会遇到任何并发问题等。
- 还有什么我应该知道的？
我有强大的Excel VBA技能，并认为我可以很快克服Access VBA，但从来没有真正完成Excel / Access链接。 我可以将数据放到Excel中，并用作准数据库，但这似乎比它更值得痛苦（而不是一个强有力的长期解决scheme）
任何意见赞赏。
亚历克斯
我相信你会得到很多的“不要这样做”的答案，我必须说，这是有道理的。 这不是一个理想的解决scheme….
话虽如此，我之前已经走过了这条路（以及类似的道路），主要是因为这个工作把它定义为一个很难的要求，我不能说这个。
以下是需要考虑的一些事情：
使用ADO / DAO从Excel中链接到Access是多么容易？ 在function方面是相当有限的，还是我可以创造性？
这相当困难。 你比使用其他工具做事更有限，因为VBA和Excel表单比大多数完整的编程语言稍微有一点局限性，但是没有什么东西可以成为展示瓶颈。 它的工作 – 有时它有点丑，但它确实有效。 在我最后一个公司，我经常不得不这样做，偶尔也会通过Excel中的VBA从Access和Oracle中提取数据。
我是否支付性能损失（使用Access中的表单作为UI）？
我的经验是肯定有一个表演。 这样做的惩罚。 我从来没有在意（在我的使用情况下，事情是足够小，这是合理的），但去Excel < – >访问速度比直接在Access中慢很多。 部分取决于你想要做什么….
就我而言，似乎是绝对最慢（也是最痛苦的）的事情是试图填写基于Access数据的Excel电子表格。 这并不好玩，而且通常很慢。 如果你不得不走上这条路，那么一定要用隐藏/隐藏的Excel来做所有的事情，否则重画就绝对会杀了你。
假设数据库将始终使用Excel VBA中的ADO / DAO命令进行更新，这是否意味着我可以让多个Excel用户使用该单个Access数据库，而不会遇到任何并发问题等。
你几乎将Excel用作客户端 – 就像使用WinForms应用程序或其他工具一样。 Access的ADO / DAO客户端相当不错，所以你可能不会遇到任何并发问题。
这就是说，访问不能很好地扩展。 如果你有2个或3个（甚至10个）用户，这很好。 如果你将有100，你可能会遇到问题。 此外，我倾向于发现Access需要定期维护，以免发生腐败问题。 Access DB的定期备份是必须的。 按照我的经验，定期压缩访问数据库将有助于防止数据库损坏。
还有什么我应该知道的？
你这样做是困难的。 使用Excel命中Access将比直接使用Access做更多的工作。
我build议您查看一下Access VBA API – 其中大部分与Excel相同，所以您将有一个小的学习曲线。 不同的部分使这更容易。 您还将拥有Access报表和表单的所有优点，这些表单比Excel中的更加面向数据。 报告对于这样的事情来说是非常好的，从macros观和报告的angular度来看，长期来看，这将会让生活更轻松。 如果用户将使用表单来pipe理所有事情，那么在Access中执行这些表单与在Excel中执行这些表单非常相似，而且看起来几乎完全相同，但是会使一切更快更顺畅。
我一直这样做。 如果您使用的是ADO，那么您并不是真正使用Access，而是基础数据库Jet。 这意味着任何有Excel的人都可以使用该应用程序 – 访问不是必需的。 哦，我应该提到，我工作的地方买了一堆办公室小型企业许可证 – 没有访问。 在这里工作之前，我会假设任何有Excel的人也会有Access。 不是这样。
我为Access中的每个表创build一个类。 我很less通过ADO运行查询，而是在类模块中保留该逻辑。 我使用SELECT语句读入，并使用ADODB.Connection对象的Execute方法写出UPDATE或INSERT。
见http://www.dailydoseofexcel.com/archives/2008/12/21/vba-framework-ii/
如果你想看看我如何设置我的代码。
回答你的问题：如果你已经知道Excel VBA，那对你来说将是一个小小的学习曲线，但是还有一些学习要做。 在Access中你会付出一定的性能损失，但这并不坏，只有你可以决定是否值得。 你可以有多个人访问数据库。
只需跳过excel部分 – excel用户表单只是一个穷人版本的更强大的Accessforms。 另外访问VBA是相同的Excel VBA – 你只需要学习Access的对象模型。 通过一个简单的应用程序，您不需要编写多lessVBA，因为在Access中，您可以很容易地将事物连接起来。
如果最终用户具有Access，则可能更容易在Access中开发整个事物。 Access内置了一些所见即所得的表单devise工具。
除非在Excel中运行用户表单有很大的优势，否则我将使用100％Access解决scheme，将报表和数据导出到Excel中。
从你所描述的来看，Access似乎是为了处理数据而build立的更有力的竞争者：
你将有更多的工具来解决任何数据问题，而不是必须绕过Excel的限制，并将其变为Access。
至于你的问题：
-
好简单。 关于这个问题，还有一些其他的问题。
看看这个和那个 。 -
不知道，但我猜想可能会有一个小小的惩罚。
我看到的最大困难是试图获得Access提供的所有function，并在Excel中重新创build其中的一些function。 -
是的，您可以拥有多个Excel用户和一个Access数据库。
在这里，使用Access作为前端并将数据保存在networking中的链接Access数据库中将更有意义，并且很容易，Access中的向导甚至可以帮助您实现这一点： 只需单击一下即可 。
真的，正如大多数人所说的那样，花一点时间来熟悉Access，它将为您节省大量的时间和麻烦。
您可以更好地了解Excel，但是如果您已经了解了VBA并熟悉了Office对象模型，就已经走了80％了。
在Access中使用它的其他优点： Access 2007运行时是免费的 ，这意味着如果您将应用程序部署到1台或30台PC，那么您将花费相同的费用： 什么都不是 。
您的开发工作只需要一个完整版本的Access（Runtime没有devise者）。
这真的取决于应用程序。 对于一个普通的项目，我build议只使用Access，但是有时需求是特定的，Excel电子表格可能更合适。
例如，在一个为前雇主开发的项目中，需要通过表单上的不同人员进行访问（预先填写一些数据，每个人不同），然后让他们完成，然后重新导入数据。
由于表单使用了大量的数据处理，因此在Excel中构build它更有意义。
不同人的Excel工作簿是使用VBA从模板构build的，然后保存在合适的位置，并具有文件夹的访问权限。
所有工作簿都使用命名范围作为外部表附加到工作簿。 然后我可以从Access应用程序查询工作簿。 所有pipe理的东西都是从数据库创build的，但最终用户只能访问他们各自的工作簿。
以这种方式开发Excel / Access应用程序是一种愉快的体验，并且UI比使用Access更加用户友好。
我不得不说，在这种情况下，在Access中使用Excel需要花费更多的时间。 此外，应用程序对象模型似乎更好，但在Excel中比在Access中。
如果您打算使用Excel作为前端，不要忘记locking所有的单元格，但是可编辑的单元格，不要害怕使用被屏蔽的行和列（为访问数据库构build输出表，执行中间计算等）。
您还应该在导入数据时closures自动上传function。
使用Excel作为Access数据的报告工具是非常简单和高效的。 快速的“非编程”方法是设置链接到外部数据源的列表或数据透视表。 但是这已经超出了Stackoverflow的范围。
编程方法可能非常简单：
strProv = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & SourceFile & ";" Set cnn = New ADODB.Connection cnn.Open strProv Set rst = New ADODB.Recordset rst.Open strSql, cnn myDestRange.CopyFromRecordset rst 而已 ！
考虑到Access的易用性，我并没有看到一个令人信服的理由，除了导出用于数字处理的数据外，其他所有方面都使用Excel。 Access旨在轻松构build数据表单，并且在我看来，使用Excel将比使用Excel更轻松，更省时。 学习Access对象模型的几个小时将花费很多时间和精力。
我是在我的一个项目中做的。 我使用MDB存储有关账单的数据，并使用Excel来渲染它们，从而为用户提供适应的可能性。
在这种情况下，最好的解决scheme是：
-
不要在Excel中使用任何ADO / DAO 。 我在MDB模块中实现了所有的公共function，并直接从Excel中调用它们。 通过调用具有必要参数的MDB函数，您甚至可以返回复杂的数据对象，如string数组等。 这与现代Web应用程序的客户机/服务器体系结构类似：您的Web应用程序只是执行渲染和用户交互，数据库和中间层则位于服务器端。
-
使用Excel表单进行用户交互和数据可视化。
-
我通常有一个最后一个工作表，有一些名称区域的设置：MDB文件的path，一些设置（当前用户，密码，如果需要等） – 所以你可以很容易地调整你的Excel实现到你的不同位置“结束“数据。
将Excel连接到Access使用VBA是非常有用的，我每天都在我的专业中使用它。 我使用的连接string是根据以下链接中find的程序。 该程序可以自动执行多个连接或任务，但基本的连接代码看起来是一样的。 祝你好运！
它取决于您期望Excel的多lessfunction< – >解决scheme。 在许多情况下，如果您没有足够的预算来获得完整的应用程序解决scheme，那么这些小工具就可以运行 如果项目范围是有限的，那么我会select这个解决scheme，因为Excel可以根据您的需要灵活地devise电子表格，然后您可以使用这些预先devise的表格供用户使用。 在Access中devise一个类似于表单的电子表格是比较费时和困难的，并且需要一些ActiveX。 它的对象不仅可以处理数据，而且可以像电子表格一样在电子表格中显示，所以这个解决scheme应该在有限的范围内工
你可以尝试像XLLoop 。 这使您可以在外部服务器上实现Excel函数（UDF）（提供多种不同语言的服务器实现）。
例如，您可以使用MySQL数据库和Apache Web服务器，然后使用PHP编写函数将数据提供给用户。
顺便说一句，我在这个项目上工作，所以让我知道你是否有任何问题。