I keep getting this "the request failed with http status 401: Unauthorized." error when i access the web app from a client machine.
my configuration:
client - client1
asp.net app - dev1
rs server/db - dev2
sql db - dev3
i'm using nt authentication
the following vb.net code is used for creditentials
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
and yes i do have impersonate = true
however, i do have aIf you impersonate client in you Web App you are hitting the limitation of
NT authentications. NTLM impersonation only survives one machine hop.
client->dev1 is OK, however dev1->dev2 is not possible after that. You need
to enable Kerberos delegations for this.
If you are not impersonating client in your web app, you need to run your
web app under account, known to machine dev2, such as domain account and
give that account rights to report server.
--
Dmitry Vasilevsky, SQL Server Reporting Services Developer
This posting is provided "AS IS" with no warranties, and confers no rights.
--
---
"mg" <mg@.discussions.microsoft.com> wrote in message
news:6B13373C-36E8-409A-BE6A-1FE8EBF6F31D@.microsoft.com...
> I keep getting this "the request failed with http status 401:
Unauthorized." error when i access the web app from a client machine.
> my configuration:
> client - client1
> asp.net app - dev1
> rs server/db - dev2
> sql db - dev3
> i'm using nt authentication
> the following vb.net code is used for creditentials
> rs.Credentials = System.Net.CredentialCache.DefaultCredentials
> and yes i do have impersonate = true
> however, i do have a
>
Showing posts with label status. Show all posts
Showing posts with label status. Show all posts
Thursday, March 22, 2012
Accessing agents status!
Hi everybody...
I'm testing a system with one distribution server and 2 subscribers
(pointing to 2 different publications on server)(planning to add other 7
subscribers on it!). I'm using bidirectional transactional replication.
Sql server 2000 is installed everywhere. All the system works fine. Data
is being updated on subscribers with a rate of about 100 records each
minute.
In that system one of the testcases is to disconnect one of the
subscriber (no more data is written in it!) for 60 minutes or more, the
reconnect it. When i reconnect it I have 2 problems:
1 - My agent is stopped (i'm using PUSH subscriptions...). I've heard
that it's the normal behavior when using a push subscription, but
there's a way to avoid it? Maybe with some triggers/stored procedures?
2 - Atfer reconnection the subscriber and restarting the agent that
stopped all the agents start working and sincronizing data. But if i
start writing data in the data that has just been reconnected, all the
data i put inside it is not sent to server and goes to conflict tables!
First question: Can i do something about that?
I tryied to do it all again but this time i've waited all the agents to
finish syncronising the data writen when the subscriber was "down". This
could be an acceptable procedure to me but I have to "tell" the normal
user to that the agent has synconized everything and he can start
writing on the subscriber.
Second question: Is there a way to look at the agent status (not using
enterprise manager!!)? I'm open minded to all kind of solutions...
Running scripts, stored procedures, writing my own small program (maybe
using some libraries... maybe RMO?).
And Thank you in advance for any
feedback
Fabio,
this is a script I use to examine the state of a job:
http://www.replicationanswers.com/Do...nningJobs.txt.
You could use it to decide what to do. To have your agent automatically
restart when connectivity is reestablished, a simple solution is to not have
the continuous schedule but a schedule once a minute. However, in this case
the above script won't really be helpful. So, I'd have a job that runs every
minute and does sp_start_job to start the merge agent, but only if it is not
already running (use my script for that). On the subscriber, if the merge
agent isn't running (again my script) you could prevent user access if you
want to avoid conflicts.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
"Fabio Pliger" wrote:
> Hi everybody...
> I'm testing a system with one distribution server and 2 subscribers
> (pointing to 2 different publications on server)(planning to add other 7
> subscribers on it!). I'm using bidirectional transactional replication.
> Sql server 2000 is installed everywhere. All the system works fine. Data
> is being updated on subscribers with a rate of about 100 records each
> minute.
> In that system one of the testcases is to disconnect one of the
> subscriber (no more data is written in it!) for 60 minutes or more, the
> reconnect it. When i reconnect it I have 2 problems:
> 1 - My agent is stopped (i'm using PUSH subscriptions...). I've heard
> that it's the normal behavior when using a push subscription, but
> there's a way to avoid it? Maybe with some triggers/stored procedures?
> 2 - Atfer reconnection the subscriber and restarting the agent that
> stopped all the agents start working and sincronizing data. But if i
> start writing data in the data that has just been reconnected, all the
> data i put inside it is not sent to server and goes to conflict tables!
> First question: Can i do something about that?
> I tryied to do it all again but this time i've waited all the agents to
> finish syncronising the data writen when the subscriber was "down". This
> could be an acceptable procedure to me but I have to "tell" the normal
> user to that the agent has synconized everything and he can start
> writing on the subscriber.
> Second question: Is there a way to look at the agent status (not using
> enterprise manager!!)? I'm open minded to all kind of solutions...
> Running scripts, stored procedures, writing my own small program (maybe
> using some libraries... maybe RMO?).
> And Thank you in advance for any
> feedback
>
I'm testing a system with one distribution server and 2 subscribers
(pointing to 2 different publications on server)(planning to add other 7
subscribers on it!). I'm using bidirectional transactional replication.
Sql server 2000 is installed everywhere. All the system works fine. Data
is being updated on subscribers with a rate of about 100 records each
minute.
In that system one of the testcases is to disconnect one of the
subscriber (no more data is written in it!) for 60 minutes or more, the
reconnect it. When i reconnect it I have 2 problems:
1 - My agent is stopped (i'm using PUSH subscriptions...). I've heard
that it's the normal behavior when using a push subscription, but
there's a way to avoid it? Maybe with some triggers/stored procedures?
2 - Atfer reconnection the subscriber and restarting the agent that
stopped all the agents start working and sincronizing data. But if i
start writing data in the data that has just been reconnected, all the
data i put inside it is not sent to server and goes to conflict tables!
First question: Can i do something about that?
I tryied to do it all again but this time i've waited all the agents to
finish syncronising the data writen when the subscriber was "down". This
could be an acceptable procedure to me but I have to "tell" the normal
user to that the agent has synconized everything and he can start
writing on the subscriber.
Second question: Is there a way to look at the agent status (not using
enterprise manager!!)? I'm open minded to all kind of solutions...
Running scripts, stored procedures, writing my own small program (maybe
using some libraries... maybe RMO?).
And Thank you in advance for any
feedback
Fabio,
this is a script I use to examine the state of a job:
http://www.replicationanswers.com/Do...nningJobs.txt.
You could use it to decide what to do. To have your agent automatically
restart when connectivity is reestablished, a simple solution is to not have
the continuous schedule but a schedule once a minute. However, in this case
the above script won't really be helpful. So, I'd have a job that runs every
minute and does sp_start_job to start the merge agent, but only if it is not
already running (use my script for that). On the subscriber, if the merge
agent isn't running (again my script) you could prevent user access if you
want to avoid conflicts.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
"Fabio Pliger" wrote:
> Hi everybody...
> I'm testing a system with one distribution server and 2 subscribers
> (pointing to 2 different publications on server)(planning to add other 7
> subscribers on it!). I'm using bidirectional transactional replication.
> Sql server 2000 is installed everywhere. All the system works fine. Data
> is being updated on subscribers with a rate of about 100 records each
> minute.
> In that system one of the testcases is to disconnect one of the
> subscriber (no more data is written in it!) for 60 minutes or more, the
> reconnect it. When i reconnect it I have 2 problems:
> 1 - My agent is stopped (i'm using PUSH subscriptions...). I've heard
> that it's the normal behavior when using a push subscription, but
> there's a way to avoid it? Maybe with some triggers/stored procedures?
> 2 - Atfer reconnection the subscriber and restarting the agent that
> stopped all the agents start working and sincronizing data. But if i
> start writing data in the data that has just been reconnected, all the
> data i put inside it is not sent to server and goes to conflict tables!
> First question: Can i do something about that?
> I tryied to do it all again but this time i've waited all the agents to
> finish syncronising the data writen when the subscriber was "down". This
> could be an acceptable procedure to me but I have to "tell" the normal
> user to that the agent has synconized everything and he can start
> writing on the subscriber.
> Second question: Is there a way to look at the agent status (not using
> enterprise manager!!)? I'm open minded to all kind of solutions...
> Running scripts, stored procedures, writing my own small program (maybe
> using some libraries... maybe RMO?).
> And Thank you in advance for any
> feedback
>
Subscribe to:
Posts (Atom)