ASP and Database Development

For several years , developers of Windows Forms database applications were at a disadvantage when it came to building Internet-enabled database apps. Active Server Pages (ASP) was easy to learn, easy to use, and free. That's a hard combination to beat.

ASP is a Microsoft technology that generates Web pages containing embedded data. Input fields within forms are used to send data back to the server. Inside a Web page that collects data, a statement like <form target=" xxx .asp"> directs the contents of the page to an ASP program (named xxx .asp here) that extracts the contents of any input fields and uses them to update tables in a database.

But ASP and even its successor ASP.NET are not the only answer. In fact, for most applications, they're not even a good answer. Browsers like Internet Explorer and Netscape

Navigator have remarkable capabilities, but they're best for distributing a simple interface to a large number of unknown users. When it comes to complex applications like billing and purchasing systems, sophisticated inventory or payroll applications, and other programs that might accomplish a task in a few seconds or in an hour depending on the capabilities of the user interface, browser clients are a poor choice.

Applications having only a few users who need precise combinations of information and more complex controls such as combo boxes, tree views, and filtered lists are difficult to build for a browser environment. A smart client application (the latest name for a database application that connects to a database over the Internet) can allow users to do the same task in seconds instead of minutes. Repeat that task hundreds of times a day, and a smart client application can soon achieve savings that will pay for the cost of development in short order.

Development costs are another saving. Paradoxically, although browser applications tend to be simpler in the sense that a single screen may only do one or two things rather than the entire set of operations that a user needs to do, they also take longer to design and code. And smart clients are cheaper to maintain as the inevitable requests for changes are made.

Finally, besides being slower than their rich client cousins and costing more to develop and maintain, browser applications send their contents as plain text. That's no way to distribute the company's sensitive information; somewhere, some hacker will intercept and read their contents.

For all three of these reasons, many developers feel that thin client application development has been hugely oversold. There are several reasons that come to mind.

• IT managers who are tired of the problems inherent in deploying traditional Windows applications to operating systems that may range from Windows 95 through Windows XP and beyond are partly to blame.

• In addition, it can be very difficult to diagnose problems in your own Windows software when someone else's installation overwrites a DLL that your application depends on, and that certainly makes a technology that doesn't need to be deployed appear even more attractive.

• Finally, people who bought a book on ASP and learned it in a week and who are excited by the salaries that database developers earn are also guilty of overestimating the applicability of ASP to database development.

You can't draw a picture of a car and drive it away, but building a Web page that sort of works is pretty easy. However, it will seldom duplicate the performance of an executable. User complaints don't begin until a poorly designed system is deployed, and by then it's too late. Windows Forms applications with well-designed interfaces based on well-designed databases provide the best combination of cost, performance, and features.

Browser applications have their place, but in time users will come to realize that it's a pretty small place. For everything else, there's rich client.

Still, getting access to data has never been easy. Traditional Visual Basic applications used recordsets internally, but recordsets aren't files, but rather in-memory structures that can't easily be sent across the Internet.

XML solves that problem. XML files are text files that express all data fields as strings delimited by tags that reflect the name of the field that the data came from. An inline schema included at the beginning of the file (or named internally and provided in another file) can describe how to reconstruct the table, if it's needed. However, when sending a known record structure to a known client, the table structures are usually known in advance. So XML is a simple way to send data from a server to a client and back again.

However, as you'll see in the examples shown in this chapter, you can send DBFs and FPTs across the Internet, and they work great. When zipped and encrypted, they provide data security in about one-seventh the space required for the equivalent XML. I wonder why Microsoft didn't decide to use them as the basis for Internet data interchange as a complement to XML. You'll have to ask them.

Microsoft and others developed Simple Object Access Protocol (SOAP) to enable remote access to a data server. SOAP provides descriptions of the functions and procedures available on a server in such a way that the client can discover what is available from a Web service and exchange data with it. A Web Services Description Language (WSDL) file is available at the server and can be queried by the client application to discover available services and their required parameters.

The implications for database applications are tremendous. You can open up an empty table structure and go to a Web server for data. After modifying a record, or after entering a new record, you can send it back to the Web server to update the appropriate database table. Deleting records is even simpler; you can just send the table name, a key field name and a key value, and the Web service can create and execute a DELETE command on the data table.

With the inclusion of support for XML Web Services in Visual FoxPro 8, FoxPro applications have begun to look like database applications written in .NET languages. Data acquisition involves creating a proxy for the remote Web Service, data translation to and from XML strings, and learning about diffgrams . It's a little different, but the results are spectacular.

In this chapter we'll add Internet access to the data tier developed in our FoxPro application in Chapter 2, "Building Sample Applications in Visual FoxPro and Visual Basic .NET,"and we'll add XML Web Services to our Visual Basic .NET application developed in Chapter 3, "Building a Visual FoxPro Application for SQL Server." I'm going to describe two methods of building Internet access for FoxPro, one for use with Visual FoxPro 7 and another for use with Visual FoxPro 8. Visual FoxPro 7 has less Web Services support than subsequent versions, and not everyone has upgraded.

I can't talk about Internet-enabled FoxPro applications without mentioning the amazing Web Connection, a product developed by Rick Strahl of West Wind Technologies on Maui. Rick is the pioneer who led the way in showing how to incorporate Web access into FoxPro applications. His shareware product is still the easiest and fastest way to build Internet applications in FoxPro, and in Visual FoxPro 7, it's by far the best way. So the first part of this chapter will describe how to use Web Connection to build an Internet application. In Visual FoxPro 8, Web Services are fully supported, so the Visual FoxPro 8 Web server will be built using native Visual FoxPro 8 capabilities. However, you might still end up concluding that Web Connection is the best way to build Internet support in any version of FoxPro. You be the judge.