gdspeare
asked on
OPENDATASOURCE Sometimes fails
I have a view created by OPENDATASOURCE. The view is
SELECT *
FROM OPENDATASOURCE ('SQLNCLI','Data Source = mydatasource;trusted_conne
.dbname.tablename
Randomly I get the following error when I run a select on the view from my workstation.
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
OLE DB provider "SQLNCLI" for linked server "(null)" returned message "Invalid connection string attribute".
If I immediately log into the server and run it there (with no problems) I can jump back to my desktop and run it (almost like I cleaning out some memory or something).
So I wanted to see if there was an execution count that would trigger the error. I ran a loop selecting * from the view for well over an hour on my machine.. The query was executed over 225,000 times. When it was done, I ran the select statement alone ~5 times with no problems. I leave my session for a few minutes I come back and get the error again and of course log into the server run it come back…no problems.
Any ideas?
SELECT *
FROM OPENDATASOURCE ('SQLNCLI','Data Source = mydatasource;trusted_conne
.dbname.tablename
Randomly I get the following error when I run a select on the view from my workstation.
Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
OLE DB provider "SQLNCLI" for linked server "(null)" returned message "Invalid connection string attribute".
If I immediately log into the server and run it there (with no problems) I can jump back to my desktop and run it (almost like I cleaning out some memory or something).
So I wanted to see if there was an execution count that would trigger the error. I ran a loop selecting * from the view for well over an hour on my machine.. The query was executed over 225,000 times. When it was done, I ran the select statement alone ~5 times with no problems. I leave my session for a few minutes I come back and get the error again and of course log into the server run it come back…no problems.
Any ideas?
No, use standard security is what I meant, sorry.
Integrated security and trusted connection set to true are the same.
So, should be:
SELECT *
FROM OPENDATASOURCE ('SQLNCLI','Data Source = mydatasource;UserId=Your_U
.dbname.tablename
Integrated security and trusted connection set to true are the same.
So, should be:
SELECT *
FROM OPENDATASOURCE ('SQLNCLI','Data Source = mydatasource;UserId=Your_U
.dbname.tablename
ASKER
why do you think think this would address the ocassional error? I can run it just fine.
plus this is going into an app. users won't be entering any credentials.
plus this is going into an app. users won't be entering any credentials.
>>plus this is going into an app.
Web app, you mean? Your original post didn't indicate that.
if it is .net, you may wish to consider adding <impersonate = "True">
>>users won't be entering any credentials.
True. They don't have to because once you create an account on the db useing SQL Server Authentication Mode and add you give it read or execute or whatever permission you wish to give it, and you enter that account into your code as I indicated, then it will authenticate any user accessing the app.
Web app, you mean? Your original post didn't indicate that.
if it is .net, you may wish to consider adding <impersonate = "True">
>>users won't be entering any credentials.
True. They don't have to because once you create an account on the db useing SQL Server Authentication Mode and add you give it read or execute or whatever permission you wish to give it, and you enter that account into your code as I indicated, then it will authenticate any user accessing the app.
ASKER
what you are suggesting makes sense. However, it doesn't aswer the question of why my query bombs out from my workstation after some event (which i can't identify) and then is successful after I run the query on the server directly.
I'm also not convinced that I would get the same issue b/c I'm an admin on both boxes. So if i'm running into this issue a sql specific account would too
I'm also not convinced that I would get the same issue b/c I'm an admin on both boxes. So if i'm running into this issue a sql specific account would too
What I think is happening is that in your iis, you are using windows integrated authentication which means that anyone accessing your app must be a windows domain user.
So, when you log in as an admin, by default, you have sysadmin account and things work fine.
If you try to run without a domain account, you run into the issue you are having.
So, the decision you have to make is whether to allow all users to have domain account OR, you do as I suggested and use ONE SQL Server account that has both execute and and atleast readOnly permission.
So, when you log in as an admin, by default, you have sysadmin account and things work fine.
If you try to run without a domain account, you run into the issue you are having.
So, the decision you have to make is whether to allow all users to have domain account OR, you do as I suggested and use ONE SQL Server account that has both execute and and atleast readOnly permission.
ASKER
i'm not using IIS - I'm logged into the server user SSMSE on my workstation and when the query fails I log into a full install on the server.
I haven't integreated the query into the asp app because of this issue.
I haven't integreated the query into the asp app because of this issue.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
not what I was hoping to learn, but it seems like this is my answer. Thanks.
Open in new window
because you are using trusted connection, anonymous login will always fail.