我正在使用 QBXML 方法与本地计算机上的 QuickBooks 进行通信（不是远程，不使用 Web 连接器）。
我有一个非常基本的脚本，它只连接到 QuickBooks 并检查客户是否存在。该脚本在通过命令控制台 (Windows XP) 运行时可以完美运行，但相同的脚本，没有任何更改，在作为 CGI 运行时不起作用。
当作为 CGI 运行时，脚本不会从 QuickBooks 获得响应 XML。其他一切似乎都完全一样——只是没有从 QuickBooks 收到 XML 响应。
昨晚我把头撞在墙上 2 个小时试图弄清楚......没有成功。
一般来说，当某些东西在命令行上有效，但在另一个环境中无效时，这意味着您缺少环境变量或存在权限问题。
您可以通过说来诊断环境变量
#!/usr/bin/perl
print "Content-type: text/plain\n\n"
print "$_ => $ENV{$_}\n" for keys %ENV;
在命令行和通过 CGI 上。
从服务调用时，QuickBooks 桌面 SDK 连接被拒绝。这是直觉强加的故意限制，但据我所知，原因从未披露过。应用程序必须在交互式登录用户的上下文中运行才能建立连接。我不确定深渊网络服务器为什么工作，它是否在与登录关联和交互登录的帐户下运行？
过去可以从服务打开 SDK 连接，但帐户限制在几年前就出现了，没有大张旗鼓或解释。有一种方法可以解决这个问题：您可以使用 DCOM 将 SDK 请求程序作为单独的进程启动，然后使用 DCOM 配置为 DCOM 进程分配适当的帐户。您可以在 SDK 文档和 Intuit 论坛中找到有关如何执行此操作的详细信息。
保罗，原来深渊也有同样的问题，当它最初安装时我以为它是作为服务运行的。重新启动时，与 Apache 相同的问题。无论如何，当 QB 未运行且未打开文件时，我还注意到在更改 QB 文件时存在很多不稳定性。不是最好的设置，但目前最重要的是，我所做的工作最终不会出现奇怪的行为或错误。所以结论是：
如果通过 Web 服务执行 QB SDK 的工作，至少如果 Web 服务器与 QB 在同一系统上运行，则 Web 服务器必须从命令（作为控制台应用程序）而不是服务运行。
最好不要让集成应用程序在 QB 文件关闭且 QB 未运行时对其进行更改。这个更烦人，但现在我只想选择有效的方法。
我将暂时跳过 DCOM 解决方法，不熟悉通过 Perl 执行此操作。
我只是希望 QB 处理速度更快。在用于测试的 1.6GHz 上网本上，它需要 6-20 秒来完成最少的处理。尽管如此，能够自动处理大量内容所获得的速度足以弥补处理速度的缓慢。
事实证明，这不是代码或环境，似乎对于这种特殊情况（QB SDK、OLE/XML），在 Apache 作为服务下运行时从 QuickBooks 获取响应 XML 的能力是问题所在。通过控制台运行的 Apache 工作正常。当然，这是行不通的，因为我需要它作为服务运行，所以我将使用 Abyss Web Server 代替，它在它下面运行良好。