vba 在本地或服务器上运行 Excel 自动化
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/12732498/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Running Excel automation locally or on server
提问by ElPresidente
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
想要一些关于哪种方法是更好的做法的意见。我们有一份必须以非常特定的格式生成的销售报告（包括行颜色和字体）。
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
我已经编写了一个宏，它从我们的数据库中提取并在大约 15 秒内填充整个工作簿。问题是它应该如何填充？
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
1) 处理服务器端：用户在内网页面发起请求。ASP.NET 打开工作簿模板，执行宏并返回最终工作表。
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
2) 本地处理：用户下载空白模板，从桌面运行，自动连接数据库。
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
我喜欢第一个，因为我可以强制执行模板、时间、用户和数据的安全性。但是是否推荐在 Internet Web 服务器上运行 Excel 自动化？我喜欢第二个选项，但我担心随着模板表开始在公司中浮动而失去标准化。
回答by whardier
As for server side:
至于服务器端：
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
我非常.. 非常.. 建议检查电子表格的 OpenOffice/LibreOffice XML 格式。
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
您可以在无头模式下使用 localc 二进制文件将 XML 文件转换为 XLSX 或您所拥有的。我用它来创建 PDF 文件，而不是使用 ReportLab。
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
或者，这里有一些其他项目尝试直接写入 Microsoft 格式：
http://pypi.python.org/pypi/xlrdhttp://pypi.python.org/pypi/xlwt
http://pypi.python.org/pypi/xlrd http://pypi.python.org/pypi/xlwt
As for client side:
至于客户端：
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
如果您希望用户只使用 Excel 而不是任何其他电子表格软件，那么请继续使用 ODBC 数据源。除非每次加载数据时都使用一些有趣的 VBScript 来从 HTTP 服务器中提取数据，否则必须为每个用户配置 ODBC。还可以选择制作一个 XLS 电子表格，该电子表格仅包含数据并将其包含到 XLS 文档中，这既是服务器又是客户端 XLS 的要求。
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
去服务器端。使信息易于存档和共享，并且很可能也是多平台的。
回答by dmarietta
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
如果您喜欢使用第一个选项，那么您希望避免在服务器上已安装的 Excel 实例上使用 VBA。这是非常资源密集型的，并且不能很好地扩展。相反，如果您正在编写 ASP.NET 代码，那么您应该尝试使用内置于 .NET 框架中的 Microsoft Office Interop 功能。应该可以通过一些更改来调整您现有的 VBA 代码以在 ASP.NET 下运行，但最终您将拥有一个更可靠的产品。
However, as @whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.
然而，正如@whardier 在他的回复中指出的那样，如果这是针对大型或公共站点，他提出的建议会更合适，并且会进一步扩展。
