您可以在fme服务器中创建数据库连接，为什么其中一个选项不是sde连接？他们不能这样管理吗？
就我个人而言，我通常在FME服务器上将不带用户名/密码的连接文件作为共享资源发布。这样连接文件就相当静态了。
我还发布了一个小的配置文件作为共享资源，通常是一个ini文件，因为它们很容易被人和脚本读取。在我的工作区中，我有两个Python脚本参数，用于从In I文件中提取用户名和密码，该文件用于ArcSDE reader的“覆盖凭据”设置。
工作很好，但是在将数据库密码放在纯文本文件中时应该小心一点，除非您对谁有权访问它有一个明确的把握。
我很想知道在使用fme服务器时，其他人正在为sde连接文件管理做什么。
从我们的角度来看…
“发布”连接文件
在处理sde连接时，必须考虑sde连接文件存储位置的利弊。
当将工作区发布到使用sde连接文件的fme服务器时，fme工作区将自动检查它是否与工作区一起上载。使用默认值意味着FME将把连接文件放在与工作台相同的文件夹（存储库）中。赞成：这是一个简单的方法。反对的论点：当密码更改时，需要重新发布工作区。因为sde连接文件在fme工作区的存储库中…使用该用户（密码已更改）的任何工作区也需要重新发布。如果只有几个工作区使用连接文件，这不是什么大不了的事情，但是如果有几十个呢？你给谁打电话？
如果你大量使用sde连接文件，你可以采取两种方法之一，使你的生活更容易。
（一）使用文件服务器：将sde连接文件放在unc可访问的文件服务器上，否则称为网络共享。在fme工作区中引用此网络共享位置（使用unc ex.//
2个）使用FME服务器共享资源：发布引用SDE连接文件的工作区时，您可以选择要将连接文件上载到的FME服务器的共享资源文件夹之一。这意味着文件在服务器上是持久的，并且可以被发布到fme服务器的其他工作区引用。赞成从FME Workbench发布时，您可以看到这些文件，并且可以通过FME服务器WebUI来确认它们的存在。您可以在需要时上传和替换连接文件（确保在现有工作区中引用相同的名称）。反对的论点：复制连接文件。此时，这些连接文件将是来自其他网络位置或其他桌面的副本。因此，仍然需要管理FME服务器系统共享上的连接文件（例如。密码更改时替换连接文件）。
安全
连接文件的另一个考虑因素是安全性。访问读/写连接文件的用户-具有更新或删除权限的存储数据库用户…也许这是一个问题，因此您可能需要重新考虑如何将连接文件存储在FME服务器上，为此目的创建一个新的FME服务器系统共享文件夹，以限制访问。
摘要
因此，在使用sde连接文件和fme服务器时，您需要记住一些想法。使用unc路径可能是最有意义的，但是你在打赌，没有人会改变它们。如果无法实现这一点，也许可以使用fme服务器系统共享，从而限制其他应用程序与fme工作区使用的连接文件交互的机会。
我们很好奇其他人在做什么，所以请分享你的想法。它可以帮助我们更好地管理sde连接文件。