Crystal Reports: How to run an application as a service

Basta Software sells a program called "AppToServe." This installs as an NT service. You then configure it to run your external Applications. See notes below on what NT is and what a Window Service is.

This is a clever approach, but it's not without its drawbacks. For example, you have one more service taking up resources. You also have one more point of failure. And it's a point of failure now common to however many applications you are running with that service.

If you need a program that schedules your Crystal Reports as a service, we have a clean way to do this. See our cViewSERVER scheduler for Crystal Reports.

cViewSERVER is available as a standalone application. If you already run our  cViewMANAGER scheduler for Crystal Reports, you can upgrade to cViewSERVER.

Running cViewSERVER is a much better way to go than buying the Basta product and configuring it to work with your system and with a third-party scheduler. Some of the reasons are:

1. Eliminate a point of failure.

2. Reduce resources overhead on the server.

3. Isolate scheduling functions from a common point of failure.

4. Reduce support costs.

5. Increase reliability.

6. Simplify administration.

This doesn't mean you shouldn't buy the Basta product or some other AppToServe product. It just means you don't have to do that to schedule your Crystal Reports.

Windows NT

For those who don't know, NT is the kernel behind several variations of Windows. It stands for "New Technology" and was developed by Dave Cutler at Microsoft. Due to internal political  problems that drove Dave batty, he quit Microsoft and began racing cars.

Windows 95 (based on DOS) was the beta for the NT4.0 UI. The next releases of Windows (2000, XP, Vista, w7) kept this same OS but just moved menu items around (often with no purpose or sense of logic), changed the graphics, and added security features.

App vs. Service

Examples of applications include Microsoft Word, Windows Explorer, and Internet Explorer. These typically are not running when you log in or boot up. You have to open them.

Services are programs most users have never heard of. Examples include Alerter, Logical Disk Manager, and Event Log. Many users are familiar with some services, such as Security Center. Windows services typically are running when you log in or boot up, though a service may be set to automatic, manual, or disabled mode via the Services interface (accessed via the Control Panel).

By default, Windows services do not run as a real user. They run as a virtual user with administrative rights on the machine. If you see "LocalSystem" for the user ID of a program, you are looking at a Windows service.

The working directory for a Windows service is typically c:\WINNT, which is the normal designation for the Windows system directory. The default temporary directory is typically c:\WINNT\TEMP. There is no home directory for this virtual user. Consequently, a service can't directly store user-specific data.

This virtual user "LocalSystem" doesn't have access to such resources as network file shares, either. Providing it with such access requires configuring it to run as a domain user with access specified. But doing this gets it out of the pure Windows service role, and saddles it with a password. That brings additional issues and housekeeping baggage.

One big advantage a Windows service has over a Windows application is you don't need a user logged in for the Windows service to run. This resolves many security issues. If a program doesn't really need a user for it to do its thing, then it makes sense to write that program as a Windows service.