我试图解决Windows 2008服务器上运行时试图连接到“Timberline数据源”ODBC驱动程序崩溃的问题，如果调用是在“服务”上下文，但成功，如果调用是在远程桌面手动启动会话。
我已经设置了服务作为我的用户运行。
我想知道是否所有其他的都是平等的（用户，机器等）， 是否有作为服务运行一个stream程与手动之间的任何基本的安全/环境差异？
—实施细则—
如果它对任何人都有帮助，我有一个系统开始尝试使用ODBC和通过IIS 7调用的Python CGI脚本连接到Timberline数据库。然而，脚本本身工作正常，只要我尝试执行ODBC连接function，脚本崩溃而不会抛出exception。 当通过命令行执行脚本时，脚本能够正常连接。
使用C＃/。net服务时也会发生同样的事情，试图通过Apache，Windows Scheduler甚至第三方调度工具来运行。
最后一个选项（第三方调度工具，pycron）该服务被configuration为以我的域用户身份login，并具有相同的问题（我通过任务pipe理器确认运行用户的stream程实际上是我）。
此外，如果重要的话，Timberline DSN被configuration为通过UNC（“\\ timberline-server \ Timberline Office \ Accounts \ AT”或其他类似的东西）来定位数据库。
DSN设置在“系统DSN”级别 ，根据ODBCpipe理工具，这意味着DSN可用于用户和服务
我也意识到，正如Joel所指出的，服务器有一个映射的驱动器（“Y：”映射到“\\ timberline-server \ Timberline Office”）
看起来数据库在共享上。 默认情况下，服务在System on Network帐户下运行，很可能无法访问共享数据库的位置。 当您在您的帐户下运行它时，脚本可以访问数据库，因为您可以访问Windows共享。
您需要将服务设置为使用服务帐户运行（即为此创build一个名为YOURDOMAIN \ svc_timberline的用户），然后将该服务帐户权限授予包含该数据库的文件夹。
它应该在那之后工作。
正如一些用户提到的， 映射驱动器只能通过交互式login会话来build立 ，即在后台服务中不可用。 仔细研究之后，我意识到，当我的DSN通过UNC指向一个networking位置时， 实际的ODBC连接器被devise成指向一个映射的驱动器 。
由于在这种情况下，我无法修改驱动程序configuration，所以我能够更新我的服务来即时映射驱动器。 因此，当我的python脚本被调用时，它会在调用ODBC连接之前映射驱动器，从而解决崩溃问题。
如果有人有类似的问题，我用这些python函数来映射我的脚本中的驱动器。
感谢所有的帮助！