>>Hello,
>>
>>I am working on creating a program which will be used as a service.
>>
>>In a nutshell, the program will consist of one form with a timer on it. The timer will run 24/7 and call a procedure every # minutes. The procedure will connect to SQL Server and based on some table/rows values will send email(s).
>>
>>Mainly the form will have a textbox which will show the end user the timer interval. My goad is to run the form minimized so that it won't be seen on the server. And the user will be able to change the timer interval by changing the text box value.
>>
>>A question:
>>
>>Can a program used as a service have a Form? Would the use have to stop the service to bring up the form to make a change?
>
>One common architecture is to have 2 different processes:
>
>1. A service which is run under some service account such as "Local System" or "Network Service". This is typically configured to start when the computer starts up and runs 24/7
>
>2. A separate UI EXE which lets a user monitor the status of the running service, and change its configuration (assuming the user has sufficient privileges). This can be run on-demand by the user, or it can be configured to auto-start when a user signs in
>
>Most of the items you see in your System Tray/Notification Area that are related to services, are designed this way.
>
>To answer your question, my understanding is the service process cannot have any UI. If it did, that UI would appear in the context of the Local System/Network Service account, which is not any signed-in user. So even if the service process is allowed to have a UI, that would effectively be meaningless as it would not be be seen by any user.
>
>If products such as ServiceMill and Always Up ease this process, I don't know the details of how they do it.
>
>All that said, for the use you describe I second Jeff's suggestion to schedule an EXE to run your procedure every XX minutes, rather than have it run all the time and rely on a VFP timer. As he suggested, make it bulletproof and code it so it gets its configuration from, and writes status/error messages to XML or TXT files. Reports or other output can be to other formats such as e-mail, which is your goal.

Thank you very much for your input. I will design the program with the form and a timer and see if it works as a Service. But I will account for the fact that it may need to be scheduled and run from the Windows Scheduler.
Ideally I would prefer to not to rely on Windows. But in the end it will all depend on how the customer wants to run it: as a service or as an EXE from the scheduler.