Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Articles
Search: 

Introduction to Database Applications on the Web
Rick Strahl, January 1, 2001
For the last several months I've been developing Internet related apps using Visual FoxPro exclusively. Ever since I started on this venture the demand for Internet apps has been tremendous and the results using Visual FoxPro have been excellent. Several of the apps I worked on were conversions of e...
Summary
For the last several months I've been developing Internet related apps using Visual FoxPro exclusively. Ever since I started on this venture the demand for Internet apps has been tremendous and the results using Visual FoxPro have been excellent. Several of the apps I worked on were conversions of existing apps to Visual FoxPro for speed reasons - the move from ODBC to a Visual FoxPro data backend resulted in a 3-5 fold increase in query speeds as well as a great reduction of processor load on the Web server's CPU. Visual FoxPro makes for a great database back end for Web applications in many situations (I'll discuss this in more detail below).
Description
For the last several months I've been developing Internet related apps using Visual FoxPro exclusively. Ever since I started on this venture the demand for Internet apps has been tremendous and the results using Visual FoxPro have been excellent. Several of the apps I worked on were conversions of existing apps to Visual FoxPro for speed reasons - the move from ODBC to a Visual FoxPro data backend resulted in a 3-5 fold increase in query speeds as well as a great reduction of processor load on the Web server's CPU. Visual FoxPro makes for a great database back end for Web applications in many situations (I'll discuss this in more detail below).

In the process of building these Web apps I developed a front end called Web Connection for Visual FoxPro that I use to connect Visual FoxPro to various Web servers. I am hoping to share with you some of the insights I've gained in developing these applications and the framework here and at this month's meeting, both to stir some additional interest in FoxPro based Internet development as well as providing a rough roadmap of what it takes to get started.

Can you spell W.E.B.?

The World Wide Web is the rage these days and has been for a while now. You might think that Web browsing is a waste of valuable time - and so it may be - but it's important to understand that the technologies behind the Web are going to be driving the future of desktop computing and application development. The vast information available on the Internet is a valuable resource to developers as well as other businesses, which is the reason the Web is expanding at a tremendous rate with new sites going up continuously - new sites that will need database capabilities as soon as they realize the power of creating dynamic Web content!

As a database developer the Web will be important to you in the very near future as all of the development tools and strategies are starting to focus on the Web not only as a medium to make data available publicly, but also as a medium to distribute and present data internally within companies and even inside your own computer. We've heard a lot about distributed computing over the last few years, but the Web might be the catalyst that brings this paradigm to the masses not only for big companies but also for small businesses and even for the desktop. The idea is that the front end - the Web browser - accesses any available back end - Web servers - for information using a common interface that is platform independent. Microsoft plans to integrate the entire operating system using a common Web browser like interface to drive it all.

While the most visible aspect of the Internet is focused on the World Wide Web and the wide open Internet, it's crucial to understand that this is only part of the Web story. Many analysts, industry experts and those in charge of computer systems in large companies are viewing the internal Web - the Intranet - as an opportunity to both centralize and distribute applications more widely at the same time. The Web's ability to connect computers with a simple protocol (TCP/IP) and a standard interface (the Web browser) means applications can be made widely available and yet be maintained centrally. Instead of installing applications locally on each user's machine, users access the application via a Web browser running a Web based application stored on an application or data server somewhere on the network. Not only is the application centrally maintained, but it is also immediately accessible across the network, not only to the local workgroup but throughout the company. And since Web browsers are hyperlink based tools it's as easy as embedding appropriate links to other related applications or tools either inside of the company or on the outside World Wide Web. This is what distributed computing was meant to be.

The message is clear: The development world is going to be changing in a big way. The current state of affairs is still in its infancy and the tools will get easier to use and more powerful as time goes on. But knowing the basics of how the Internet works will be an important asset as we move on into this new world of development.

Where do we fit in?

Up until recently, much of the content available on the Web has been static, consisting of pages laid out in advance and linked together statically via hyper text links embedded in HTML (Hyper Text Markup Language - the page description 'language' used to display pages in Web Browsers) pages. While it's nice to look at beautifully designed static pages they are fairly limited: Information presented on these pages is likely to get out of date, any data presented has to be presented in large volume to be browsed through manually, and maintenance of this kind of setup for even a moderately complex data source becomes prohibitive as groupings, categories etc. have to be set up manually. Static pages are great for static information or information that really needs to be maintained manually: Home pages, individual product information pages that need lots of custom graphic content, personal information pages. However, if you need to display typical database information that involves large amounts of data the concept falls apart quickly.

The true potential of the Web can be realized only from information that is generated dynamically feeding on up-to-date information contained in databases, providing only the data that the user asks for. If this sounds to you like a typical database application, you're right! This is where we as database developers come in - it'll be our job to make the connection between existing data sources and the Web.

Web based database applications are very much a client/server job! If you're using Visual FoxPro as the data backend, you'll be implementing the server side using Visual FoxPro code. The concept is pretty simple (we'll leave the details for later in this article): The Web browser requests data from the Web server, which in turn calls your Visual FoxPro application to provide that data. In reality this means your Visual FoxPro code has to figure out what the Web server is requesting, run the code to process the relevant queries, updates, inserts etc., and then return an HTML document that either displays the requested data or a status message that indicates that the task was completed successfully.

Keep this server concept in mind when you get started - FoxPro based Web server development involves very little user interface programming. The user interface is entirely handled by the Web browser, although you will probably be building some of those Web browser input pages with data from a database! You will also be generating a lot of HTML output...

The Now and The Then

The technologies to make this happen are changing and improving at blinding speed and today's hot technology is yesterday's forgotten relic. Without a doubt Web application development will get easier than it is today. There are some exciting technologies on the horizon from Microsoft, Netscape and a variety of other vendors, but while a lot has been promised and some has been previewed, few of the promised advanced tools are available in production form to build applications with today (as of this writing anyway). If your goal is to put out apps publicly on the Web there are also compatibility issue to deal with. Microsoft and Netscape are duking it out with new, incompatible standards that make it hard to adopt one or the other's standards for development or page layout.

The newest technologies are coming, but what works today will likely continue to work in the future - remember the tried and true methods are often better than the hottest new trends especially on the Internet where buggy beta or even alpha software is becoming the norm.

Microsoft and the Web

Last month I attended the Microsoft at the movies conference that broadcast the strategic sessions from the Pacific Developer's Conference which was focused entirely on Microsoft's Internet strategy. An incredible amount of information and new tools and toolsets were announced at this conference.

First off, and this should come as no surprise, Microsoft is pushing ODBC in a big way. Microsoft is giving away its new high performance Internet Information Server and it comes with built-in database connectivity via the Internet Database Connector (IDC). The IDC is a SQL based scripting mechanism that allows you to access any ODBC datasource installed on the Web server directly. It's a simple interface that can be set up quickly to generate simple, dynamic queries based on user input. You can define SQL statements which can include input from HTML forms, Web server and browser status information. The output can be formatted using a simplistic macro language that allows for minimal programming logic to be embedded into a scripted HTML template file. To do more complicated programming with the IDC requires you dig into SQL stored procedures and triggers which can get messy quickly.

The other big news is a set of technologies that Microsoft vaguely termed ActiveX. The idea is that this technology will move us from static to dynamic or active content on the Web. The active portion of this technology is heavily focused on Web browser enhancements that will allow scripting via VBScript, JavaScript and any other languages that can be hooked into the next generation browser's open scripting engine, as well as support for 'active' OLE controls that can be controlled by the scripting language. In addition the browser can be used as an OLE document container so viewing any OLE document including full editing capabilities can be handled right within the familiar browser interface.

These tools will allow building more interactive Web applications that can have browser side, interactive data validation and field interaction, real GUI interface operation for things like autofilling fields based on user selections, showing or hiding additional areas of a form etc. (standard HTML forms lack any interactivity - once displayed the page has to be changed and reloaded). In addition, support for OLE controls means that the third party tools the VB society has been working with for years now will extend to Internet development with controls for interface gadgets, multimedia and even self contained application objects likely to show up.

The full ActiveX promise is not here yet, but Microsoft is pushing hard to get it out - the browser side extensions are promised by the middle of the year while the server side scripting extensions are not expected until the end of the year.

Visual FoxPro and The Web

It all sounds very exciting, especially if you've already worked on Web applications with the current tools. With all of this built in database connectivity and VBScript as a scripting language, where does a tool like Visual FoxPro fit in?

As always the motto should be "The right tool for the job!" The current Web tools and even the proposed MS ActiveX extensions lack what developers of modern development languages take for granted: Flexibility. Tools like Visual Basic and Visual FoxPro have tremendous functionality that allow building complex applications quickly. It will take a while for Web only tools to catch up in power and flexibility.

The current crop of Web tools provide crude macro languages or plain CGI interfaces using cryptic scripting languages which are ill-suited for heavy duty data access. There are also problems with some of the new technologies I described above. The MS Internet Database Connector is very limited: You can only supply a single SQL statement per request and the scripting language lacks many common constructs to build output properly. ODBC based datasources other than SQL servers have to run on the same machine as the Web server making them unscalable should the load on the servers get heavy - Web servers and database servers do not belong on the same machine or both will get bogged down quickly under load. As you probably know ODBC is fairly slow accessing data with local data engines and exacts a heavy processor load while processing queries; both are problematic for the high volume transactional nature of Web requests.

Visual FoxPro provides a great middle ground as a data server backend between a full scale SQL server installation and small scale low volume applications that can get by with Web server local ODBC access. Visual FoxPro's speed is a major asset in this scenario as it can provide 3 to 5 times faster data access than most local ODBC data sources (even the new VFP ODBC driver is a lot slower than VFP natively), especially if the FoxPro server is offloaded on a separate machine on the network.

Is Visual FoxPro always the right choice? No way! If data volume and simultaneous access to the Web server becomes heavy there's nothing better than a true multi-threaded, secure, SQL server that can scale the load on a single high powered machine. But for smaller installs and even moderately heavy loads, such a setup is overkill and can be much better served by a single or multiple VFP data servers. One of my Visual FoxPro Web installations is serving 20,000 CGI requests daily with more than 1 request per second at peak times all running off a single Visual FoxPro server session with no sign of maxing out yet. Adding more Visual FoxPro sessions will allow this setup to be easily scaled. Finally, don't forget the licensing fees required for SQL Server - Microsoft requires a $3000 license fee to connect SQL Server to a publicly accessed Web Server.

Connecting Visual FoxPro to the Web

The key to making traditional development languages like Visual FoxPro work with Web servers is to use an interface that allows FoxPro to read the information the server provides about itself, the client Browser and the HTML form that might have generated a request and then passing the HTML or HTTP request output back to the Web Server. Figure I shows the flow of data from a Web Browser to Visual FoxPro and back. Note the intermediate 'connector' that connects Visual FoxPro to the Web server. Such a connector is required in order to allow Visual FoxPro to act as a data server, rather than being called and loaded directly as an executable from a script call generated by an HTML link. This is necessary, since VFP is too large to be loaded and unloaded for each individual request. Instead Visual FoxPro needs to act as an already loaded server waiting for incoming requests, instantly springing to life when a request is received.

A request starts on an HTML page as either a hypertext link or an ACTION command generated from an input form. The link or form contains the name of the script (an EXE or DLL that references the connector application) that is to be executed when the link is clicked or the Submit button is pressed on the form. A typical script link might look like this:

In essence a call to a script is treated in the same fashion as a link to another HTML page, except that instead of simply opening and displaying a static page, a program (wwcgi.dll in this case) executes and returns an HTML document. Note that you can pass 'parameters' as part of the link following the ? on the URL portion of the HREF link. These 'parameters' can be used by Visual FoxPro to decide what it needs to do when receiving this request.

The connector application that passes this request on to VFP needs to provide a high speed interface that is usually written in C or other low level language to provide a small executable and low resource use on the Web server. Traditionally these connector applications are EXE files written using the Common Gateway Interface (CGI), a standard Internet protocol that describes how input and output is to be handled. A newer, Microsoft sponsored standard called ISAPI (Internet Server API) provides similar functionality with more efficient resource use and better integration into the Win32 API. ISAPI works by loading in-process DLLs that exist as direct extensions to the Web server. ISAPI DLLs are more resource friendly, remain resident once loaded and operate in the Web server's address space, all of which translates into very fast operation of the extension.

Several connector applications for Visual FoxPro have been implemented by third party tool providers and by Microsoft for their Web page wizard. Internally, these connectors let Visual FoxPro know that the Web Server has a request waiting to be processed and to get ready to process this request by sending a 'message' to the Visual FoxPro server. There are a variety of methods that can be used to pass this message to the application: Via file based messages that are polled for by the VFP server (which is what my tool Web Connection and the VFP WWWPage Wizard use), OLE messages that are sent to an OLE Automation server (this is the preferred method used to connect VB to a Web server), DDE message sent to Visual FoxPro acting as a DDE server and memory based messages that are placed in reserved areas of memory and picked up by Visual FoxPro via a FLL/DLL call. As you might expect, each approach has its pros and cons and you need to find the one that matches your needs best...

Once Visual FoxPro has control your user code (or the server's internal processing in case of the non-programmatic ones) set out to retrieve the Web server information and return an HTML page to the Web server. The Web server receives the finished HTML page and passes it back to the Web browser which displays the output on the user's screen.

What's a Visual FoxPro Data Server?

I used this term to make it clear that Visual FoxPro is running in server mode - continuously loaded in memory waiting for incoming requests from the Web server. Contrast this with typical CGI applications that are run as executables whenever the Web servers needs them. By running as a server, VFP doesn't need to start up each time, which would be totally unacceptable due to VFP's runtime size and load time. The term is also meant to describe the server's main purpose: To serve data, or more to the point HTML page output. What actually transpires as part of the data server processing is up to you and depends on the connector product you work with. The term server often conjures up an image of a fixed static process that the developer has little control over. It doesn't need to be this way however.

For example, Web Connection allows you to run any Visual FoxPro code you see fit by setting up a Procedure or Class method that handles an incoming request. Web Connection handles this by having the server process call a user defined function that contains your FoxPro code. Once you get control you can use FoxPro code to its fullest extent. In addition, Web Connection also provides scripting methods that allow you embed FoxPro code and expressions directly into an HTML page requiring only one-time setup code on the FoxPro end.

Another example. The Visual FoxPro Web Page Wizard interprets a script file, the filename of which is passed to it as part of the URL passed to it by an HTML form that contains the input form for the query to run. The Wizard's data server then processes the query and sends back the output - it's all automated for you, but you have no control over the processing other than what the Wizard set up.

Other FoxPro connector tools also provide mixtures between Visual FoxPro programming interfaces and script like capabilities that can be built into HTML pages to automate output page creation. Whichever tool you choose, you'll be able to leverage your existing FoxPro skills to create dynamic Web based content with them.

Speed, Load and Scalability

How well suited is Visual FoxPro to being a database server for a Web server? There are several issues to consider. As we all know, Visual FoxPro is very fast as a data engine, which is one of the immediate advantages of using it as a data server. Compared to the local ODBC engines VFP will finish in a fraction of the time.

Speed, however, is not the only criterion when dealing with a Web server interface. Visual FoxPro is not a multi-threaded application, so a single Visual FoxPro application can only process one Web request at once. What this means is that one request must finish before the next can be executed. For some applications that might not be a problem - if requests take a second or less and the number of requests is less than the total time the server spends on processing them user are likely getting response back in a timely fashion. When I gave the 20,000 CGI hits example above I'm referring to these kinds of sub-second response times.

Things get more tricky though when you have long requests that take 10, 20 or more seconds to run. A couple of those can pile up and cause users on the Web server to time out their connections - definitely a problem. In order to process requests simultaneously you need multiple Visual FoxPro sessions. The other sessions can run either on the same machine or (for some products anyway) run on another machine over a network.

Note that while running multiple sessions on the same (single processor) machine will allow requests to run simultaneously, both of them will slow down drastically while processing, so that this often not a good idea. Often the slow down is so drastic that a single session provides better results than multiple sessions. Still, two or more sessions on a single CPU can be a good idea if query times vary widely between short and long queries, so that a short query can be squeezed through while a long one runs.

Sounds bad, right? However, local ODBC sources suffer the same fate even though ODBC is multi-threaded. The problem is processor load - one CPU can only handle one task at a time. Simultaneous queries will only split the CPU delegation but provide no overall performance gain. Hence for heavy duty query servers a SQL server on multi-processor hardware is likely to be a better choice for a data server.

There's a way around this load problem however by adding machines to process data across the network. Web Connection allows you to run multiple sessions of Visual FoxPro over the network and access the request messages from the Web server over the network. This is a double win situation: Moving the database load completely off the Web server to give the Web server the breathing room it needs to serve Web pages, and scalability to allow multiple sessions to pick up and process requests simultaneously.

Using this approach makes a Visual FoxPro solution very scalable.

What you need to get started

Now that you have a general idea of how you can use FoxPro for Web serving here's an overview of the pieces you need in order to start developing Web applications. The diagram above points out all the major pieces required: A Web server, the required connector application along with a FoxPro front end that understands the connector's interface and a Web browser to test your creations with.

You'll also want to set up network support for the TCP/IP network protocol. If you're running Windows 95 or NT this is a no-brainer as TCP/IP is a built-in protocol that you can install with a few clicks from your Network Control Panel applet. A network is not actually required for development, though - you can develop TCP/IP applications locally by accessing the Web server via the local machine name and IP address (the local IP address for a machine is always 127.0.0.1 and the local machine can always be accessed as Localhost for a domain name. For example, http://localhost/default.htm will access the local Web server's homepage as will http://127.0.0.1/default.htm). While a true network isn't required for testing it's nice to have your test Web server set up on another machine across the network. Web servers are fairly resource intensive beasts that will slow your development machine down significantly while testing apps.

I've mentioned the MS Internet Information Server above as MS's entry into the Web server world. IIS is a good choice for a Web server since it is extremely fast, tightly integrated with Windows NT and also is available to free for the price of a download. However, there are a variety of Web servers available from other companies and many of them offer many more features than this first entry from Microsoft for additional configuration options, internal support for scripting, security etc. I've been using Commerce Builder from the Internet Factory. I started using it prior to the release of IIS and have kept on with it, because it includes support to run under Windows 95 (for testing) a fairly powerful macro language that makes it possible to create simple dynamic pages that contain logic flow and HTML parameter passing without having to call an external script. Built in macro features like counters, browser type identification, HTML form variable expansion and conditional HTML output make it possible to do most non-data related tasks right inside of HTML pages. Commerce Builder also supports many of the advanced technologies that IIS currently supports like ISAPI and ISAPI filter extensions of the Web server. Other Web servers also support macro languages as well as ODBC support via HTML macro expansion. My point is to take a close look at other servers as well as IIS before blindly 'buying' into the Microsoft line. Microsoft's strategy looks good for the future, but right now they are still behind in features that might make your development of Web apps easier. Most servers are available on a trial basis for you to check out free of charge for a limited time and prices are coming down drastically now that MS has made IIS available for free.

Web browsers are the interface to Web applications. The current state of the interface is more like a dBase II application than the slick GUI applications we've been building in recent years. This will change with interactive browser support coming via script languages and applet or OLE control plug-ins. You'll likely want to pick up copies of both Netscape and MS Internet Explorer to be able to take full advantage of the competing functionalities. Each of these two browers is pushing the HTML standard into new directions that make it easier to create flashy output pages, but unfortunately the two standards are diverging. You might find it useful to take advantage of some of the browser's advanced features by conditionally supporting these features for specific browser types. This gets pretty messy, but sometimes the usability results are worth the extra effort. We'll see enhancements to the static form interface with the introduction of browser scripting languages that will make it possible to build more GUI like interfaces. Keep in mind that these new features still need to use the methods I discussed above to talk to the Web server - in other words VBScript or JavaScript will not make a Visual FoxPro backend obsolete since these scripting languages will not be able to access data directly. They will make HTML page creation easier though with the ability of building conditional HTML logic right into the pages.

Finally, you'll need a connector application such as Web Connection, WebLink or FoxWeb, or if you're adventurous the Visual FoxPro WWW Page Wizard. These applications provide a low-level interface between the Web server and FoxPro by taking info from the Web server and passing a ''message' to FoxPro to let it know that it needs to process the request. The connectors allow you to use Visual FoxPro as a data server that's up and running waiting for requests. When a request is received control is passed to the VFP server which in turn is responsible for creating an HTML page as output. Depending on the tool, the data server might process the entire request without any code required (canned queries or scripted pages) or it might call your user code that you can run to generate queries etc to build the output yourself taking advantage of the full power of the FoxPro language. Similar products exist for Visual Basic and other development environments.

Getting it online

Once you've decided to create a Web based application you have to deal with another important issue: How will the app be deployed? If you're building an Intranet application this will be a fairly easy proposition as the local or wide area network will host the application. Remember though that the network must be running the TCP/IP protocol in order to support access to the Web server.

If you're going online to the Internet the issues become more complex. If your app goes to a large corporate client it's quite possible that the Web server can be directly linked to the Internet from the client's site. If possible, this is the ideal situation as the Web server and your FoxPro application are sitting at the client site where it's easy to control and debug should problems arise. This is an expensive proposition, though, and probably not an option for a small to medium sized business unless volume (sales or referrals) justifies the expense.

The other option is to choose an Internet Service Provider (ISP) that can host the application for you. Usually this means you get to install a machine on the ISP's network and hook into the existing TCP/IP network to host your application and possibly your own Web server. Not all ISPs allow such an arrangement, so you might have to dig deep to find one that will allow co-location at a reasonable price. Preferably you want to find an ISP that runs a Windows based system so you can hook into their existing Web servers rather than running your own. Your machine can then act as a data server only across the network with the ISP handling the Web server administration. This is the current setup that I have with my ISP - they're running about 20 sites (5 of which are data sites powered by my VFP stuff) . The ISP handles Web server setup and management for all sites, all I have to worry about is my data server machines and the Visual FoxPro code that runs on them.

Be aware though that co-location requires a good relationship with your ISP as you will need both physical and remote access to your machine for updating code, recovering the occasional crashed session etc. You will also need full network access to your machine so you can update files remotely - a security risk that ISPs are often worried about. Finding an ISP for co-location is not easy. A good selling point on your part might be to let the ISP know that helping you set up shop brings them business as well - your clients will need business accounts and a domain name on the ISP's system in order to go online which generate consistent income for ISPs.

Administration

Using Visual FoxPro as a Web data backend requires some care. Since VFP is running in server mode any code crashes or lockups will essentially stop the server from responding to further requests. It's crucial to build your server application bullet proof. Web Connection deals with this with a set of error handlers that catch most errors, log them, and recycle the server when not running in DebugMode. Still even with this scheme it's possible to crash the code with successive errors, invalid file paths (a file Open box can hang the server for example) or an infinite loop. There's also the issue of updating code. The data server needs to be shut down in order for the application code to be updated.

When that time comes, you'll need a remote access tool to pick up the pieces from the comfort of your office. I've been using LapLink95 which is an extremely well integrated remote communications package and a joy to use. LapLink works very well for controlling my main Windows 95 box that hosts the Visual FoxPro data server, but unfortunately it does not work under Windows NT. For NT I'm using pcAnyWhere32, which works but is not nearly as well done as LapLink and lacks some handy features like the ability to start up before the Windows log on so you can actually shut down and restart the machine remotely. One of these packages is a must for remote administration of your server

Not so final words

Whew... lot of ground covered here in fairly general terms. I hope that this overview has given you a better idea of how the Web fits into your future. But keep in mind that things are changing fast and that other technologies aside from FoxPro are going to figure largely. VBScript and OLE control integration will likely bring Web development out into the open. It'd be foolish to overlook these tools just because they're not FoxPro based, especially since they can co-exist very nicely.

Rick Strahl, West Wind Technologies
Rick Strahl is an independent developer on Maui, Hawaii. His company West Wind Technologies specializes in Internet Application development focused on Internet Information Server, ISAPI, C++ and Visual FoxPro. Rick is author of West Wind Web Connection, a powerful Web application framework for Visual FoxPro, West Wind HTML Help Builder, co-author of Visual WebBuilder, a Microsoft Most Valuable Professional, and a frequent contributor to FoxPro magazines and books. His book, Internet Applications with Visual FoxPro 6 is available from Hentzenwerke Publishing. He's also a frequent speaker at various FoxPro user conferences.
More articles from this author
Rick Strahl, December 1, 2002
West Wind Technologies has presented a one of a kind 3 day conference on WWC prior to the GLGDW conference in Milwaukee. This conference was geared towards existing WWC and general VFP Web developers with specialized topics presented by several speakers in this session style conference. Speakers inc...
Rick Strahl, January 1, 2001
By now you've undoubtedly heard that object oriented programming has arrived in Visual FoxPro. Many aspects of Visual FoxPro are implemented using objects by extending the existing FoxPro language with a great implementation of object oriented (OO) extensions. The OO implementation in Visual FoxPro ...