Threading and database connections

[jacques.steward@gmail.com]

I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?

[ignacio machin]

RE: Threading and database connections

Is this a web app?

Are you using imporsonate ?

"jacques.stewar d@gmail.com" wrote:

I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?
>
>

[Peter Bromberg [C# MVP]]

RE: Threading and database connections

If you want, you can have the process run under the credentials of a user
that has the required database access. In web.config,
<identity impersonate="tr ue" userName="theUs er" password = "thePasswor d' />

Bear in mind that this does expose some security issues, but try it first
because it is a very "easy fix".
Peter

--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

"jacques.stewar d@gmail.com" wrote:

I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?
>
>

[jacques.steward@gmail.com]

Re: Threading and database connections

I added the line in the web.config file you suggested. It doesn't
appear that the processing thread ever proceeds. The monitor page is
updating properly. If I add records to the table it is monitoring it
appears on the status page.


Peter wrote:

If you want, you can have the process run under the credentials of a user
that has the required database access. In web.config,
<identity impersonate="tr ue" userName="theUs er" password = "thePasswor d' />
>
Bear in mind that this does expose some security issues, but try it first
because it is a very "easy fix".
Peter
>
--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

>
>
>
>
"jacques.stewar d@gmail.com" wrote:
>

I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?

[Peter Bromberg [C# MVP]]

Re: Threading and database connections

If you are using SQL Server, you can just supply a SQL Server login uid and
pwd in your connection string instead of using Windows Authentication,
provided that mixed mode authentication is enabled.
Peter

--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

"jacques.stewar d@gmail.com" wrote:

I added the line in the web.config file you suggested. It doesn't
appear that the processing thread ever proceeds. The monitor page is
updating properly. If I add records to the table it is monitoring it
appears on the status page.
>
>
Peter wrote:

If you want, you can have the process run under the credentials of a user
that has the required database access. In web.config,
<identity impersonate="tr ue" userName="theUs er" password = "thePasswor d' />

Bear in mind that this does expose some security issues, but try it first
because it is a very "easy fix".
Peter

--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

"jacques.stewar d@gmail.com" wrote:

I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?
>
>

>
>

[jacques.steward@gmail.com]

Re: Threading and database connections

Thanks so much for your help. Once I followed your advice I was able
to see that the problem was not the tread but the permissions on the
database. Apparently it was using my privileges when updating but it
was defaulting to the application default when control was passed. The
default privileges were not enough on a couple of tables so the tread
was bombing out without any indication as to why.


Peter wrote:

If you are using SQL Server, you can just supply a SQL Server login uid and
pwd in your connection string instead of using Windows Authentication,
provided that mixed mode authentication is enabled.
Peter
>
--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

>
>
>
>
"jacques.stewar d@gmail.com" wrote:
>

I added the line in the web.config file you suggested. It doesn't
appear that the processing thread ever proceeds. The monitor page is
updating properly. If I add records to the table it is monitoring it
appears on the status page.


Peter wrote:

If you want, you can have the process run under the credentials of a user
that has the required database access. In web.config,
<identity impersonate="tr ue" userName="theUs er" password = "thePasswor d' />
>
Bear in mind that this does expose some security issues, but try it first
because it is a very "easy fix".
Peter
>
--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

>
>
>
>
"jacques.stewar d@gmail.com" wrote:
>
I have an application that kicks off a long process on the database
server with a separate thread and then forwards the user to another
page which monitors the progress of this process by reading a table
that is being updated by the long process. On my development machine
it works fine but when I try to deploy the app to a server the long
process is blocked from database access. Apparently when the new
thread is created it either does not get or loses its credentials. On
my dev machine it is not a problem because it simply reverts back to my
credentials but on the server it reverts back to the default IIS user.
How can I work around this?