AFP 3.0 is more than just an application executing .afp files. For those interested in the details, there will be more of it in the sections below. The following is based on a typical AFP application. Under normal circumstances, this application is located in a directory on the Web server. The application may be set up as a sub-directory (http://www.prolib.de/shop) or defined as a separate virtual Web (http://shop.prolib.de). Which of the two solutions you choose depends on your Web server and your system constellation.

All .afp files of an application are located in a single directory. Ancillary files like images etc. may frequently be in a separate directory. Occasionally, data have been deposited in a sub-directory; this was the simplest option under the previous versions. For security reasons we recommend to deposit this data in a directory outside the scope of control of the Web server.

If you run only one application on the Web server, you need not worry about application interaction. In all other cases the following explanations are of paramount importance. All requests to a Web server – independent of the directory or Web concerned – are directed to one single AFP3.DLL. This DLL will forward the request to an AFP instance that is available. Thus, any AFP instance can on principle answer any request. No classification in applications, Webs, etc will be made. 

Each AFP instance is completely separated from all others. AFP instances run in different memory areas and do not share variables, files, or objects. If e.g. the session variables produce this impression, it is because there is special code in AFP that causes this behavior. In actual fact, all session variables are saved to the FoxPro MEM file and loaded in all instances.

AFP are based on the FoxPro SESSION object. Therefore, each application has its own data session where it can open files at will. PUBLIC variables and numerous settings on the other hand are valid for all AFP applications. If an application makes modifications to one of these settings, it should return the setting to its previous state at the end of each page. If this is not done, it may cause erratic behavior of the other applications on the server. Applications are loaded into each instance. Thus, if you run multiple AFP instances – which is typically the case – you will also have multiple instances of the application.

For this reason you cannot open files exclusively in one application. The other instances would not be able to open the table concerned. By the same token you won't be able to deposit data applying to all instances with APP.SetData. Even the global objects created by them are only available in one instance. It is also important that the user won’t always be directed to the same instance. You should therefore save temporary files to session files rather than to cursors.

To set up an application, create a file .afpa in your application directory with this content:

<application ID="…"/>

Adjust the value of ID. This value must be unique to each application on the Web server and may only consist of letters, numbers and underscores. Observe the appropriate case. These are XML files which differentiate between upper case and lower case letters. There may only be one .afpa file per directory. Whenever an .afp file is invoked AFP 3.0 looks for the corresponding .afpa file in the same directory. If no unique file is found, the search will continue with an extensive search algorithm. Details are discussed in a subsequent chapter. Here we want to say this much: if AFP 2.4 compatibility is activated, the application C24_Fox.afpa will be used in this case. If no compatibility mode is set, a page without application will execute. The latter case should be avoided.