在本地或在服务器上运行Excel自动化
想知道哪种方法是更好的做法。 我们有一个销售报告，必须以非常特定的格式生成（直到行颜色和字体）。
我已经写了一个macros从我们的数据库中拉出，并在大约15秒内填充整个工作簿。 问题是如何填充？
1）进程服务器端：用户在内网页面发起请求。 ASP.NET打开工作簿模板，执行macros并返回最后的工作表。
2）本地进程：用户下载空白模板，从自动连接到数据库的桌面运行。
我喜欢第一个，因为我可以强制执行数据的模板，时间，用户和安全性。 但build议在互联网web服务器上运行Excel自动化？ 我喜欢第二种select，但是当模板开始在公司周围浮动时，我害怕失去标准化。
至于服务器端：
我非常高兴..build议检查电子表格的OpenOffice / LibreOffice XML格式。
您可以在无头模式下使用localc二进制文件将XML文件转换为XLSX或您有什么。 我用它来创buildPDF文件，而不是使用ReportLab。
另外这里有一些其他的项目试图直接写入微软的格式：
http://pypi.python.org/pypi/xlrd http://pypi.python.org/pypi/xlwt
至于客户端：
如果您希望用户只使用Excel而不使用其他电子表格软件，请继续使用ODBC数据源。 每个用户都必须configurationODBC，除非每次加载时都使用一些有趣的VBScript从HTTP服务器上获取数据。 还可以select制作XLS电子表格，该电子表格只包含数据并将其包含在XLS文档中，这也是服务器和客户端XLS的要求。
去服务器端。 使信息简单归档和共享，很可能也是多平台的。
如果您喜欢使用第一个选项，那么您希望避免在服务器上安装的Excel实例上使用VBA。 这是非常资源密集型的，并不能很好地扩展。 相反，如果您正在编写ASP.NET代码，那么您应该尝试使用内置于.NET框架中的Microsoft Office Interopfunction。 它应该有可能适应你现有的VBA代码在ASP.NET下运行一些变化，但最终你会有一个更可靠的产品。
示例代码
但是，正如沃尔迪尔在回答中所指出的那样，如果这是一个大规模的公共场所，他所提出的build议将更为合适，而且可以进一步扩大规模。