> I realize that by design, web client/server interaction is disconnected.
>   I'm wondering if there is a way that when a client/server interaction
> occurs, if there is a way to start a time on the web server which will
> run some code after a specific amount of time (or variable amount of
> time), such as send an e-mail.
>
> We have a page that is a ticket page (computer support ticket page) that
> employees use to submit a help/trouble ticket to IS. I want to be able
> to have an e-mail sent back to their email account after a variable
> amount of time, say, between 2 and 5 minutes. I already have a message
> sent back when they submit their ticket, but I need to delay the
> response email to them somehow. Any pointers?
>
> TIA,
> Jim

> Hello Jim,
>
> I can think of a few ways to do this, for example:
>
> 1) Use message queues (MSMQ ala System.Messaging) and only read
> messages that are of a certain age
> 2) Use SQL Server Service Broker queueing (if you have SQL 2005) and do
> the same
> 3) Create a system.threading.timer, and set it to go off after a
> certain amount of time elapses and execute your code
> 4) Create a simple work queue table in your DB, and mark the age of the
> entries. Use a service program running on the server to retrieve the
> messages and do the work.
>
> Personally, I would consider 1 and 2 first, because they are by the
> most reliable, but they can be heavy to implement. 3 and 4 are easy to
> implement. But 3 might not be the most reliable choice. Let me know
> what you choose to do. In a jam, I'd do number 4.
>
> -KJ
>

> KJ wrote:
> > Hello Jim,
> >
> > I can think of a few ways to do this, for example:
> >
> > 1) Use message queues (MSMQ ala System.Messaging) and only read
> > messages that are of a certain age
> > 2) Use SQL Server Service Broker queueing (if you have SQL 2005) and do
> > the same
> > 3) Create a system.threading.timer, and set it to go off after a
> > certain amount of time elapses and execute your code
> > 4) Create a simple work queue table in your DB, and mark the age of the
> > entries. Use a service program running on the server to retrieve the
> > messages and do the work.
> >
> > Personally, I would consider 1 and 2 first, because they are by the
> > most reliable, but they can be heavy to implement. 3 and 4 are easy to
> > implement. But 3 might not be the most reliable choice. Let me know
> > what you choose to do. In a jam, I'd do number 4.
> >
> > -KJ
> >
>
> I'm not very advanced when it comes to dev (VB/ASPNET OR SQL), so most
> of what you said went over my head pretty high. Option 3 sounds like
> something I may be able to implement with much help and guidance.
>
> When creating a system.threading.timer object, I'm guessing I do it
> something like:
>
> Dim objTimer As System.Threading.Timer
> objTimer.
>
> And that's as far as I get. There's a few options but I don't know which
> one to use or how to implement it.
>
> I also noticed in the object browser that there's System.Timers
> namespace. I can't imagine that would work on a page since client/server
> interaction is disconnected. I guess that's where threading comes in
> instead?

> KJ wrote:
> > Hi Jim,
> >
> > Glad to hear back from you. I've been thinking a bit more about using a
> > threaded timer, and I am now feeling that this is not the best
> > solution, especially for a newer developer.
> >
> > I think there is an easy way to do this, but it will require some
> > design work. A few questions first: are you using a database platform
> > such as SQL Server for your application? If so, do you have much
> > experience on that platform?
> >
> > -KJ
> >
>
> I'm running a 2003 server (IIS6) with SQL2000 Standard (also on same web
> server). I have a little knowledge of it, such as basic SQL commands and
> basic server administration. I've considered upgrading it to 2005 but
> always a little nervous about upgrading a production server. Since my
> databases are very small and I've no large or imperative stored
> procedures, views or triggers, I'm sure upgrading wouldn't be a problem.
> I am planning on doing so soon, if I can get over the potential upgrade
> disaster fear.
>
> The internal website that i've mostly built has about 6 simple databases
> . Each database has no more than, say, 6 tables, with maybe two of them
> related and the others just lookup tables. I've never used stored
> procedures until recently when I decided to make a few to give them a
> try, since I heard its the more secure way to go and better performance.
>
> This whole delayed code execution thing isn't completely necessary. It
> was a side thing I was going to do to make things look a bit less, um,
> computer controlled. ;)