我们有一个在Windows Server 2003和IIS6上运行的ASP Classic网站，它会抛出所需的间歇性运行时错误424对象。我们已将此跟踪到初始化对象元素的对象引用的行，如下所示（第二行）：
MetaBasePath="IIS://" & ComputerName & "/" & StorageKey & "/" & DataAccessKey
Set ConfigKey=GetObject(MetaBasePath)
DataSource=ConfigKey.Get("ODBCDataSource")
UserName=ConfigKey.Get("ODBCUserName")
Password=ConfigKey.Get("ODBCPassword")
我已经搜索了stackoverflow（以及一般的网页），看是否有其他任何人遇到此问题的迹象，但是已经空白了。有没有人有任何想法可能导致这个？是否有任何与性能相关的设置可以控制对Metabase的访问频率？我们可以采用哪种最佳实践措施来提高Metabase访问的效率？假设我们通过隐藏数据库中的数据库访问详细信息来做正确的事情，或者在安全性方面是否过度，我们是否正确？
此问题会影响我们大约1％的网页点击次数。
我们正在研究一系列操作，包括检查服务器软件组件的补丁级别，并可能围绕上述代码添加一个循环，以便在Metabase对象初始化正确之前继续尝试，但这最多只是一个短期修复在我看来。
建议最欢迎！ 谢谢， 克雷格。
其他信息：刚刚发现IIS5.0隔离模式已启用。我试图找出为什么启用这个但这可能是相关的吗？
答案 0 :(得分：1)
IIS元数据库不是为了安全，而仅仅是为了方便。
它只是几个虚拟服务器（IIS / ASP应用程序）共享数据的中央存储库。因此，如果仅出于安全目的使用它，则根本不需要Metabase。
由于：
您是谁“隐藏我们的数据库访问详细信息”？程序员？但他已经获得了它。将ConfigKey.Get("ODBCPassword")分配给密码后，任何response.write都会显示该密码。即使在global.asa中完成，您也必须将其转换为连接字符串（或将其存储在Application变量中），以便.asp页面可以创建数据库连接对象。在Metabase和对象创建之间的某个时刻，他将可以访问连接属性。
甚至认为关于通过在global.asa创建连接对象并将对象本身存储在Application变量中来防止这种情况。 （从而将创建隐藏在程序员可访问的文件中）。这不仅会破坏连接池，还会导致巨大负面性能下降。
如果您担心ASP页面的数据库安全性，我建议采用以下方法：
为网站访问创建不同的数据库用户，权限非常有限。含义SELECT，INSERT，UPDATE，DELETE和EXECUTE（存储过程）仅。没有DROP，CREATE，ALTER等。这样，任何“密码泄漏”或“程序员误用”都不会严重损害数据库。具有完全权限的“admin”用户密码永远不会在网站的任何地方访问（或使用）。
创建ActiveX（或COM，DCOM）DLL以包装连接设置。它可以用C＃，VB.NET甚至经典的VB6编写。它将从另一个（安全和web-innacessible）服务器文件读取登录名和密码，创建连接对象，并直接将其传递给ASP。
所以不要使用：
set objConn = Server.CreateObject("ADODB.Connection")
ASP页面将使用：
set objConn = Server.CreateObject("MYCLASS.Connection")
配置文件本身甚至可以加密，因为decripit算法将存储在已编译的代码中，而不是存储在纯文本ASP文件中。
那就是说，我不是说Metabase没用。它仍然是一个存储数据的好方便的地方，因为：
可以在不更改任何代码行的情况下更改数据
有几个网站可以共享数据，即使每个网站都有自己独立的应用
集中数据总是比保持配置和包含遍布文件系统的文件更容易保护
用户/ NTFS许可证的设置方式只允许授权人员更改数据，但网站用户（和ASP开发人员）只能读取数据
也就是说，“有限的数据库用户”+“COM类连接包装器”是大多数公司使用的方法。当然，关注安全的人。其他人只使用“global.asa中硬编码的连接字符串，然后存储在应用程序变量中”。