Internet Access in Visual FoxPro 7

Building a Web-enabled smart client in Visual FoxPro is a lot like building a SQL Server application. You use local cursors , get as little data as possible, and pass it around using HTTP.

Visual FoxPro 8 has great support for Internet access. However, many Visual FoxPro developers haven't upgraded, so I'm going to start by showing you how to use Web Connection to build Web-enabled database applications in Visual FoxPro 7. After that, we'll see how Visual FoxPro 8 has added new features that permit development of the same type of applications without using a third-party tool (although you may decide to stick with Web Connection anyway). Finally, we'll see how completely XML Web Services are integrated into Visual Basic .NET, so that very little needs to be done to Web-enable your application.

The first time I read the sentence "The Internet Is The Network," I thought, with my typical Hungarian cynicism: Right. More marketing BS to sell something. Then I spent a few months with Rick Strahl's Web Connection.

Let me make one thing perfectly clear: The Internet Is The Network.

If you haven't yet built your first Web-enabled database application, please, please take the time to implement the code in this chapter. It will change your life ”professionally, at least.

For this example, I'll use the shareware version of Web Connection. Go to www.west-wind.com and download it. When you've finished this chapter, you can either send Rick $129 for your shareware, or $399 for the whole enchilada. I'd point out some of the additional features included in the complete package, any one of which would be worth the whole price of Web Connection, but I would just start sounding like a salesman , which I'm not; I'm just a very, very satisfied customer. Go ahead, download it. I'll wait right here.

Good, you're back. Let's get started.

Installing Web Connection

First, install Web Connection. I say this as one might say "slice a tomato," but installing Web Connection and configuring your Web server is undoubtedly the most challenging part of this entire exercise. There are four distinct pieces of software involved here, and the database application we're going to write is only one of them. There's Microsoft Internet Information Server (IIS), which comes with Windows but must be installed separately; there is SQL Server, which is a career in itself; and there are the two programs that you're going to write ”one for the workstation and the other for the server.

One odd thing you'll soon notice is that the application doesn't have any data files on the client side. That's right, no DBFs. In fact, the entire application when installed, regardless of the number of screens, usually consists of one executable. It's kind of eerie to fire it up and watch data come over the wire. But that's how it works.

It does so by asking a Web server to go to an application server (a FoxPro program that you'll write) that will ask SQL Server (or FoxPro DBFs) for data. The Web server, application server, and SQL Server can be running either on your development machine, on another computer on your LAN, or anywhere on the Internet. During the development phase you'll run both the client and the server on the same computer and then move the server software to a server that can be accessed from anywhere on the Internet.

You must have installed a Web server on the computer before installing Web Connection. The Web server is either Personal Web Server, Internet Information Server 5 (Win2K/XP), or perhaps another such server.

To install Web Connection, extract it to a directory called wconnect on your C: or D: drive, and then run the SETUP.EXE program in the wconnect directory. (When you install it, it will try to run SETUP itself.) It will install the software and prepare two special directories that are used by Web Connection in addition to the \wconnect directory where the server program is installed.

Three conditions must be met during the setup process: IIS has to be correctly installed and running; you will have to set it up to point to a virtual directory that contains part of your server software; and the computer's administrative account must have execute rights to the virtual directory where a little program called wc.dll is going to be installed. If any of these three conditions isn't met, you will have zero, I repeat, zero success. And, these three conditions have nothing to do with the FoxPro programs you're going to write.

I've spent days, maybe weeks, verifying these conditions. They are the heartbreak of Internet programming. However, if you follow Rick's instructions carefully , it will eventually work ”unless you're trying to run under Windows 98, in which it may or may not work. So I strongly urge you to do all of this on a computer that's using either Win2K or XP for an operating system. That's the bad news.

All of the rest is good news.

Building Your Application

The truly peculiar part of writing Internet applications is that part of your program is running on one computer, and part of it is running on another one. Here's how it works.

Let's say you want to populate a grid with customers from the state of California. In a traditional FoxPro LAN application, you would write a SQL query like this:

 SELECT Cust_ID FROM CUSTOMER WHERE STATE = 'CA' INTO CURSOR C1 

Execute it and bind the resulting cursor to a grid on a form and voil  , you're looking at California customers.

In an Internet application, you construct something like an email that contains the SELECT statement and send it to a URL on another computer. The URL must call a program called wc.dll , which is the Web Connection component. It's one of only two programs in Web Connection that are written in C++; the rest are all written in FoxPro.

ASP supports (among other things) a Request object to read the URL you send to a server, and a Response object to send output back to the requestor . IIS takes care of intercepting the URL, running the program named in it, and returning the output (usually HTML) to the computer that sent the URL.

Wc.dll does the same thing. A Web Connection URL must include the wconnect directory, a reference to wc.dll (the connection that knows what IIS is expecting), a class name, a function name , and any parameters needed by the function. When the URL arrives, wc.dll activates the named class and passes the parameters to the named function in that class. The function first extracts the parameters passed to it using a wwRequest object. (You can't use the traditional PARAMETERS statement used in FoxPro.) The function constructs and runs the query, and then uses a wwResponse object to send back the data in XML format. Your program, meanwhile, is filing its nails and waiting for the data to come back. It sees it, drops the nail file, grabs the data and slaps it into the grid, and voil   redux.

For our example, we'll use the same form that we built in Chapter 2. The only change, it turns out, is in the Data Access Layer.

The Main Program

There are just a few changes to the MAIN program we saw in Chapter 2. They're highlighted in Listing 5.1.

Listing 5.1. The Main Program

 * Program-ID..:  MAIN.PRG * Purpose.....:  MAIN program for application CLEAR ALL CLOSE ALL CLEAR CLOSE ALL SET TALK       OFF SET CONFIRM    ON SET MULTILOCKS ON SET CENTURY    ON SET EXCLUSIVE  ON SET SAFETY     OFF SET DELETED    ON SET STRICTDATE TO 0 WITH _Screen .AddObject ( [Title1], [Title], 0, 0 ) .AddObject ( [Title2], [Title], 3, 3 ) .Title2.ForeColor = RGB ( 255, 0, 0  ) ENDWITH Global error handler (called if no TRY...CATCH block * handles an error, or if THROWn from top TRY..CATCH block. ON ERROR DO ErrTrap WITH LINENO(), PROGRAM(), MESSAGE(), MESSAGE(1) DO MENU.MPR SET PROCEDURE TO DataTier.PRG ADDITIVE oDataTier = CREATEOBJECT ( [DataTier] ) oDataTier.AccessMethod = [DBF] * Added for WebConnection support SET PATH      TO WWIPSTUFF * The next 5 lines refer to Web Connection files SET CLASSLIB  TO wwIPStuff ADDITIVE SET PROCEDURE TO wwHTTP    ADDITIVE SET PROCEDURE TO wwUtils   ADDITIVE SET PROCEDURE TO WWPOP3    ADDITIVE SET CLASSLIB  TO wwXML     ADDITIVE * The following string was needed because my laptop has a different server name. * Ordinarily the default "(local)" will be adequate. *!*    oDataTier.ConnectionString = [Driver={SQL Server};]          + [Server=VAIO\VAIO;Database=Northwind;UID=sa;PWD=;] *!*   oDataTier.AccessMethod = [SQL Server]    && Last one will be used IF NOT EMPTY ( oDataTier.AccessMethod )    READ EVENTS ENDIF ON ERROR SET PROCEDURE TO SET CLASSLIB TO SET SYSMENU TO DEFAULT WITH _Screen .RemoveObject ( [Title1] ) .RemoveObject ( [Title2] ) ENDWITH DEFINE CLASS Title AS Label Visible   = .T. BackStyle =  0 FontName  = [Times New Roman] FontSize  =  48 Height    = 100 Width     = 800 Left      =  25 Caption   = [My application] ForeColor = RGB ( 192, 192, 192 ) PROCEDURE Init LPARAMETERS nTop, nLeft THIS.Top = _Screen.Height - 100 - nTop THIS.Left=                   25 - nLeft ENDPROC ENDDEFINE PROCEDURE ErrTrap LPARAMETERS nLine, cProg, cMessage, cMessage1 OnError = ON("Error") ON ERROR IF NOT FILE ( [ERRORS.DBF] )    CREATE TABLE ERRORS (;     Date     Date,        ;     Time     Char(5),    ;     LineNum     Integer,    ;     ProgName     Char(30),    ;     Msg    Char(240),    ;     CodeLine     Char(240)    ) ENDIF IF NOT USED ( [Errors] )    USE ERRORS IN 0 ENDIF SELECT Errors INSERT INTO Errors VALUES ( ;   DATE(), LEFT(TIME(),5),  nLine, cProg, cMessage, cMessage1 ) USE IN Errors cStr = [Error at line ] + TRANSFORM(nLine) + [ of ] + cprog + [:] + CHR(13)    ;      + cMessage + CHR(13) + [Code that caused the error:] + CHR(13) + cMessage1 IF MESSAGEBOX( cStr, 292, [Continue] ) <> 6    SET SYSMENU TO DEFAULT    IF TYPE ( [_Screen.Title1] ) <> [U]       _Screen.RemoveObject ( [Title2] )       _Screen.RemoveObject ( [Title1] )    ENDIF    CLOSE ALL    RELEASE ALL    CANCEL   ELSE    ON ERROR &OnError ENDIF 

The five lines of code about 45 lines down in Listing 5.1 that are preceded by the comment "Web Connection source code" refer to the Web Connection shareware libraries, which in turn call the functions in WWIPSTUFF.DLL , the heart of the product. I've copied these lines from a startup routine that normally would urge you to send Rick your $129.00 for the shareware each time the program starts. The message has been removed, but please remember that this is shareware. If at the end of this exercise you don't think it's worth the price, I would be very surprised.