executenonquery(); timeout error

[Guest]

Hi, I' m a calling a SQL SP from ASP.net that executes a DTS package (which runs in around 10 minutes). I'm getting a timeout error. The DTS package is setup to send an email once the job completes, so I would like for the ASP to simply execute the DTS job, not attempt to wait for the job to complete

Any help would be greatly appreciated

David Jones

 

[William Ryan eMVP]

There are two places you can get a timeout, on the connection or the
command. If you know the command takes 10 minutes, then it's most likely
the command that's timing out (could be both but probably isn't).

You can specify the connection timeout only via the connection string b/c
it's read only. However the Command.TimeOut property can be set to whatever
you want it to. 0 is supposed to indicate unlimited but that has some
issues. You can just set this to some interval longer than what you expect
but less than something that'd be useless (there's a default timeout in
ASP.NET that's like 45 years or something...that's of little practical
value).

HTH,

Bill

--
W.G. Ryan MVP Windows - Embedded

http://forums.devbuzz.com
http://www.knowdotnet.com/dataaccess.html
http://www.msmvps.com/williamryan/

Hi, I' m a calling a SQL SP from ASP.net that executes a DTS package

(which runs in around 10 minutes). I'm getting a timeout error. The DTS
package is setup to send an email once the job completes, so I would like
for the ASP to simply execute the DTS job, not attempt to wait for the job
to complete.

 

[Guest]

Thank you for the reply! Is there anyway I can bypass the wait time altogether? The end user would not want to wait for the job to complete since the DTS job will email them once it has completed.

 

[William Ryan eMVP]

I'd set the command.timeout to something really long, then I'd either use an
IAsyncResult or a thread (effectively the same thing in this context) to
spin that off to another thread so it won't interrupt the user. As far as
he's concerned it's done and over with. The only possible trouble you might
get into is if they close the app while the process is still running but
that's not difficult to work around. Depending on how you are calling your
function, IAsyncResult or explicitly creating a thread are both fairly
simple to implement, but multithreaded programming isn't. If you're going
to do this, the stuff I wrote here
http://www.knowdotnet.com/articles/delegates.html will get you through it,
but I don't want to give the impression that this is all you need to konw
about threading..it's a quite complex subject and can cause some major
drama - it's definitely not something to take lightly. However don't let
that scare you. I'm babbling, never mind. Mainly just remember that
anything you refer to in your thread shouldn't be referenced in the rest of
your program. If you had a sequence like this

int i = CallToLongRunningProcess;
MessageBox.Show("Whatever");

Normally you wouldn't hit the message box line until
CallToLongRunningProcess returned. However if you use a thread, it would
hit almost immediately. This can allow for a much more responsive UI and as
far as the user is concerned the call has no bearing on how they use the
app.

I've probably just throughly confused you if you aren't familiar with
threading, and if so, please feel free to ask me anything you want to know.
Sorry if I did ;-)

Bill

--
W.G. Ryan MVP Windows - Embedded

http://forums.devbuzz.com
http://www.knowdotnet.com/dataaccess.html
http://www.msmvps.com/williamryan/

Thank you for the reply! Is there anyway I can bypass the wait time

altogether? The end user would not want to wait for the job to complete
since the DTS job will email them once it has completed.

 

[Guest]

This is great info (I found the article usefule as well). Thanks

I this particular case it's an web form, so it is likely the user will cose the form after submitting the job (or clicking the button). Can I still use this technique?

 

[William Ryan eMVP]

Sure. Anytime you want something to run asnyc and not block, another thread
is the way to go. Also, it's a good idea in many cases to run another
thread other than the UI thread for your db access. As a habit, I hardly
ever run my DB commands in the same thread just b/c they can hang for a
zillion reasons beyond my control and I hate freezing the UI or blocking the
user from doing anything. If it takes a long time, and they flip back and
forth, getting that white screen is really annoying.

HTH,

Bill

P.S. Thanks for the compliment, I really appreicate it.

--
W.G. Ryan MVP Windows - Embedded

http://forums.devbuzz.com
http://www.knowdotnet.com/dataaccess.html
http://www.msmvps.com/williamryan/

This is great info (I found the article usefule as well). Thanks

I this particular case it's an web form, so it is likely the user will

cose the form after submitting the job (or clicking the button). Can I still
use this technique?