Access databases only through an application server

A WebClient application must access databases through an application server, as the client cannot directly access a database. All of the database data presented by the application to the end user must originate on an application server. All database data entered by the end user must be sent to an application server for evaluation and storage. To pass relational-database data between an application server and client, you can use temp-table parameters in remote procedures.

Modularize your code by function

Consider this scenario: you have just designed a new application's procedures and user-defined functions, and you are now assigning each piece of code to a procedure (.p) file. At application-deployment time, you might want only certain components (groups of application files) to download initially, and other components to download only when they are first called. When you design your application, you can make deploying the application more efficient by the way you assign code to procedure files. Specifically, avoid assigning pieces of code that support dissimilar functions to the same procedure file, since you might want unrelated modules of an application to download at different times.

For example, consider an insurance application that supports several different lines of insurance: life, health, automobile, fire, and disability. Assume the application has separate code supporting each line of insurance, plus general-purpose routines used throughout the application. To modularize this application by function, make sure that:

• A single procedure file does not contain routines for more that one line of insurance.
• A procedure file containing general-purpose routines does not contain specific routines for one type of insurance.

Choose which installation types to support

Administrator installations and personal installations have different requirements. You must consider these requirements while designing your application and its WebClient deployment. An Administrator installation requires the end users have write access to certain areas that are normally restricted to administrators, but it imposes no additional restrictions on your designs. A personal installation does not have that write access, which results in some limitations. For example, a personal installation cannot:

• Install files to certain areas.

  Adding such files through the IntelliStream System Tasks causes install errors for a personal installation. For more information, see the System Tasks and personal installations.

• Install a .NET Runtime.
• Write to registry keys or files located in areas to which the non-administrator does not have access.