我正尝试在Visual Studio中从ASP.NET Web应用程序调用MicrosoftAccess函数。我能够连接到Access数据库并调用表和查询。
string connstring = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source = " + filePath;
string query = "Select * from table";
OleDbConnection connect = new OleDbConnection(connstring);
OleDbCommand command = new OleDbCommand(query, connect);
但是,我很难从ASP.NET中找到任何有关调用access数据库中的函数的信息。
微软是否有可能从微软office应用程序、Asp.net或任何其他网络服务之外访问功能?
1条答案
按热度按时间fnvucqvd1#
你有两个不同的问题。
要从Access表查询/提取数据。
这是"标准"的,而且您使用的是oleDB提供程序(在大多数情况下)。实际上,odbc提供程序通常是更好的选择。不过,让我们改天再讨论这个问题。
然而,虽然你可以使用访问数据文件从一个网站?这不是所有的好选择,因为你需要访问数据引擎安装在网络服务器上。而这往往是一个真正的问题,因为主机提供商将不会(甚至允许)安装访问数据引擎。
注意:请仔细选择上述词语:
我说的是Access数据引擎!!!那是ms-access使用的数据引擎。
但是,如果要运行/调用/使用/消费VBA代码?
然后,您需要在该Web服务器上安装ms-access。这是一个完全不同的问题。虽然在Web服务器上安装Access数据引擎可能是一个挑战,但安装Access是一个完全不同的问题。在大多数情况下,这是不允许的,也不会发生。
现在,您可以在开发人员计算机上执行此操作。
但是,有大量的问题。
首先:
您必须将MS-Access安装的位大小与您的Web服务器的位大小相匹配。默认情况下,您的Web服务器将以x64位运行。因此,这意味着您可以:
请确保您安装了ms-access x64位。
或
强制您的项目和Web服务器以x32位运行。
接下来:
调用/使用/消费/运行/享受VBA代码例程的使用?
然后,您不能只打开数据库(使用oleDB提供程序),但您必须首先创建一个完整的Access运行示例。
当你创建这个示例时,你也必须非常小心,因为在access启动时,任何启动代码都会运行。(启动窗体,VBA代码)。当你这样做时,你对会发生什么没有太多的控制!
通常,您最好创建数据库和代码的精简版本,并且只包含您调用的VBA例程。然后,您可以使用链接到实际accDB数据文件的表。
一旦你创建了MS-Access的一个完整的运行示例,那么你就可以编写所有的VBA代码例程。然而,这不是线程安全的,也不是一个好主意。无论是Word、Excel还是Access?尝试从Web服务器创建这样的应用程序的运行示例往往是一个非常糟糕的主意。在这些应用程序中弹出的任何类型的"提示"都意味着你在这一点上注定要失败。因为从Web服务器和. net代码中,您无法单击或回答任何UI提示,这些提示在启动此类应用程序时经常出现。
我所要做的是用VBA代码,创建一个新的www.example.com类(独立的)。粘贴该代码,然后将VBA代码转换为vb.net代码。它们非常接近。如果你构建了一个记录集助手类,那么你现在可以非常轻松地将相同的VBA代码(或非常接近)作为vb.net代码运行。vb.net class (stand alone). Paste in that code, and then convert the VBA code to vb.net code. They are VERY close. If you build say a recordset helper class, then you can with GREAT ease now have that same VBA code (or VERY near the same) run as vb.net code.
然后编译该类,再将该程序集添加到C#Web项目中,现在您的Web站点上运行的代码和逻辑与此相同。
以上是我推荐的方法。
我的时间很紧,但是也许今天晚上,我会回来发表你如何从c#web应用程序调用/运行VBA代码,但是尽管可能,它不被支持,更糟糕的是在一个生产web服务器和站点中?你真的没有太多的选择来确保一个完整的工作版本的ms-access将被授权和安装在该web服务器上。
我的意思是,你真的想走这条路吗,因为这是一个非常糟糕的设计决策选择。我建议你采用这段代码,并在. net代码中复制逻辑。
在这里做出真正"糟糕"的设计决策是,嗯,真的很糟糕!
编写好的可靠代码在最好的日子里是一个巨大的挑战。那么,开发人员"如何"和"为什么"编写好的代码呢?
他们做出了好的设计决策,所以他们不会以古怪的代码告终。这样的开发人员并不比你强,但他们的结果更好,因为他们一开始就避免选择导致糟糕设计的道路。
我记得我读过一本关于如何打台球的书,结果发现那些更好的球员往往不是更擅长射击主球,但他们在一杆后想把主球放在哪里做出了更好的决定。
写代码也是一样的。不是你写的代码更好或更差,而是你必须接受的设计决策更好或更差,然后随着时间的推移尝试调试+维护。换句话说,不要走一条会导致代码非常难以运行、维护、以及会降低代码库可靠性的选择。你可以很擅长编写代码,但如果代码是基于糟糕的设计决策,你仍然会努力使这样的代码以可靠的方式工作。
编辑:那么,工作示例
因此,假设在ms-access、VBA中,代码模块包含以下代码:
现在,上面只是一个示例,但是上面的VBA从表中获取数据,并将City转换为大写。
现在,我们的asp.net标记(一个按钮显示数据,一个按钮运行上面的VBA代码)。
因此,这个标记:
这段代码将用Access数据加载GV
注意非常接近,我们不是在启动访问,而只是打开数据库-消费数据。
现在,我们的下一个标记按钮,它将调用/运行/使用MS-Access中的一些VBA代码。
密码是这样的:
因此,当我们运行上述网页时,我们看到/得到以下内容: