SQL1092N “ASPNET”无权执行所请求的命令。对 dsn 的基本 ODBC 调用不起作用

发布于 2024-08-09 16:08:45 字数 2290 浏览 2 评论 0原文

不要为此向我开枪,但我也已将其发布在专家交换上。我只需要一个答案。这是问题(是的,我已经搜索、谷歌搜索、再次搜索):

我在样板 odbc 连接代码上遇到了一些非常奇怪的错误。该代码连接到 DB2(使用 DB2 总是很愉快)并且过去从未给我带来过任何问题。这是典型的工作幽灵……有一天它停止工作了。这种情况发生在两个独立的 Windows 2003 服务器实例上。在我的本地机器上,代码运行良好。该代码通过 IBM DB2 CONNECT 组件通过系统 dsn 设置进行连接。

我收到的一个错误是:

ERROR [08004] [IBM][CLI Driver] SQL1092N "ASPNET" does not have the authority to perform the requested command.

即使我将 ASPNET 帐户放入 DB2ADMINS 和 DB2USERS 组中,也会发生这种情况。我知道 DB2USERS 组应该有足够的权限,但我尝试 DB2ADMINS 只是为了好玩,但它们都不起作用。

在我的另一个应用程序中,它使用完全相同的系统 dsn(好吧,它无论如何都在尝试),错误消息只是空白......没有。堆栈跟踪显示:

at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
   at System.Data.Odbc.OdbcConnectionHandle..ctor(OdbcConnection connection, OdbcConnectionString constr, OdbcEnvironmentHandle environmentHandle)
   at System.Data.Odbc.OdbcConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.Odbc.OdbcConnection.Open()
   at code class ... line xxx            //abridged
   at form class ... line xxx             //abridged

我在这里完全不知所措...它有效...但现在不起作用...

这是 odbc 代码:

String dsn = ConfigurationManager.AppSettings.Get("DSN");

String con = ConfigurationManager.ConnectionStrings[dsn].ToString(); 
// con evaluates to "DSN=MYSYSDSN"


OdbcConnection conn = new OdbcConnection(con);

OdbcCommand command = new OdbcCommand(Constants.SQL_GET_DATA, conn);

command.CommandType = CommandType.Text; 

OdbcParameter param1 = new OdbcParameter("@param1", param1value);

OdbcParameter param2 = new OdbcParameter("@param2", param2value); 


command.Parameters.Add( param1 );

command.Parameters.Add( param2 ); 

OdbcDataReader rdr = null; 

try

{ 

  conn.Open();    //errors here w/ above stack trace and an empty message string
  .....

Don't shoot me for this, but I've posted this on experts-exchange as well. I just need an answer. Here's the question (and yes, i've searched, googled, and searched again):

I'm getting some very strange errors on boiler plate odbc connection code. The code connects to DB2 (which is always a joy to work with) and has never given me issues in the past. This is your typical work ghost....one day it just stopped working. This is happening on 2 separate instances of Windows 2003 servers. On my local machine the code works fine. The code is connecting via a system dsn setup via the IBM DB2 CONNECT components.

One error I get reads:

ERROR [08004] [IBM][CLI Driver] SQL1092N "ASPNET" does not have the authority to perform the requested command.

This happens even after I place the ASPNET account in both the DB2ADMINS and DB2USERS groups. I know the DB2USERS group should have permissions enough, but I tried DB2ADMINS just for kicks, yet neither of them work.

In my other applcation, which is using the exact same system dsn (well, it's trying to anyhow), The error message is simply blank....there isn't one. The stack trace reads:

at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
   at System.Data.Odbc.OdbcConnectionHandle..ctor(OdbcConnection connection, OdbcConnectionString constr, OdbcEnvironmentHandle environmentHandle)
   at System.Data.Odbc.OdbcConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.Odbc.OdbcConnection.Open()
   at code class ... line xxx            //abridged
   at form class ... line xxx             //abridged

I'm at an utter loss here...it worked....and now it doesn't...

Here is the odbc code:

String dsn = ConfigurationManager.AppSettings.Get("DSN");

String con = ConfigurationManager.ConnectionStrings[dsn].ToString(); 
// con evaluates to "DSN=MYSYSDSN"


OdbcConnection conn = new OdbcConnection(con);

OdbcCommand command = new OdbcCommand(Constants.SQL_GET_DATA, conn);

command.CommandType = CommandType.Text; 

OdbcParameter param1 = new OdbcParameter("@param1", param1value);

OdbcParameter param2 = new OdbcParameter("@param2", param2value); 


command.Parameters.Add( param1 );

command.Parameters.Add( param2 ); 

OdbcDataReader rdr = null; 

try

{ 

  conn.Open();    //errors here w/ above stack trace and an empty message string
  .....

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

玻璃人 2024-08-16 16:08:45

您拉入的连接字符串/数据源使用的是 Sql Server 世界中我们所说的可信连接或集成身份验证。这在测试中效果很好,因为应用程序将使用您的凭据运行,并且您有权访问数据库。

但是,当部署到服务器时,该应用程序使用名为“ASPNET”的特殊用户帐户运行。该帐户无权访问您的数据库。因此有两种方法可以修复它:

  1. 授予 ASPNET 帐户对数据库的权限。
  2. 使用模拟使您的应用程序使用不同的帐户运行。

您确实应该选择第二个选项,因为 ASPNET 帐户是本地计算机帐户而不是域帐户,并且您不希望像这样乱扔权限。它还解释了为什么将 ASPNET 帐户添加到您的组不起作用 - 它是本地帐户而不是域帐户(您可能添加了错误的 ASPNET)。

不幸的是,我无法帮助您设置模拟,因为我们在我所在的地方使用 sql 身份验证。但我可以提供一些关于改进您发布的代码的建议:

String dsn = ConfigurationManager.AppSettings.Get("DSN");
String con = ConfigurationManager.ConnectionStrings[dsn].ToString(); 
// con evaluates to "DSN=MYSYSDSN"

using (OdbcConnection conn = new OdbcConnection(con))
using (OdbcCommand command = new OdbcCommand(Constants.SQL_GET_DATA, conn))
{
    command.Parameters.AddWithValue("@param1", param1value);
    command.Parameters.AddWithValue("@param2", param2value); 

    //no need for try/catch here unless you do logging at this level
    // instead, let it bubble up for the next level to decide how to handle

    conn.Open();
    using (OdbcDataReader rdr = command.ExecuteReader())
    {
        while (rdr.Read())
        {
           // do something
        }
    }
}  // no need to call conn.Close() here - 'using' block takes care of it

The connection string/data source you're pulling in is using what in the Sql Server world we call a trusted connection or integrated authentication. This works just fine in testing, as the app will run with your credentials, and you have permissions to access the database.

However, when deployed to a server, the app runs using a special user account named "ASPNET". This account does not have permission to access your database. So there are two ways to fix it:

  1. Give the ASPNET account rights to the database.
  2. Use impersonation to make your app run with a different account.

You should really choose the 2nd option, as the ASPNET account is a local machine account rather than a domain account, and you don't want to be throwing permissions around like that. It also explains why adding the ASPNET account to your group doesn't work - it's a local account rather than a domain account (you're probably adding the wrong ASPNET).

Unfortunately, I can't help you set up impersonation as we use sql authentication where I'm at. But I can give some pointers on improving the code you posted:

String dsn = ConfigurationManager.AppSettings.Get("DSN");
String con = ConfigurationManager.ConnectionStrings[dsn].ToString(); 
// con evaluates to "DSN=MYSYSDSN"

using (OdbcConnection conn = new OdbcConnection(con))
using (OdbcCommand command = new OdbcCommand(Constants.SQL_GET_DATA, conn))
{
    command.Parameters.AddWithValue("@param1", param1value);
    command.Parameters.AddWithValue("@param2", param2value); 

    //no need for try/catch here unless you do logging at this level
    // instead, let it bubble up for the next level to decide how to handle

    conn.Open();
    using (OdbcDataReader rdr = command.ExecuteReader())
    {
        while (rdr.Read())
        {
           // do something
        }
    }
}  // no need to call conn.Close() here - 'using' block takes care of it
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文