Hi Tom.

I am relatively new to using VFP7 with SQL server. I have expermented with both Remote view and SQL pass through. I am having trouble creating a form entering data then saving is to the SQL Server without going through alot of steps.

If you are an experienced VFP developer but are new to C/S development, you may want to get Client-Server Applications with Visual FoxPro and SQL Server 7.

If you are new to VFP, then the reference book that you want is Fundamentals:Building Visual Studio Applications on a Visual FoxPro 6.0 Foundation

Finally, we present a great alternative to views in Chapter 13 of MegaFox: 1002 Things You Wanted to Know About Extending VFP.

What are the data classes?

The classes described in this chapter are based on a design originally conceived and developed in 1996 by Hue Holleran and Andy Kramek to meet a very specific set of operational requirements. Since that original implementation the classes have been extensively revised to meet a more generic set of design criteria as outlined below.

• Handle the issues associated with connecting to a specific data source. It should not matter whether this is local VFP data, or a remote SQL Database (e.g. SQL Server or Oracle)

• Handle the issues of having to connect, simultaneously, to more than one data source, even if they are of different types

• Correctly format and execute SQL Pass-Through queries irrespective of the data source type

• Manage database updates (transactions) irrespective of the data source type

• Handle connection and database errors

Design considerations for the data classes

First, and most obviously, we will need something to handle the process of connecting to a database and managing the connection. There are really only two possibilities. First, we could create a single ‘smart connection handler’ class to manage any number of connections, of any type. Second, we could create a single ‘generic’ connection class and create specific subclasses for each type of connection required.

The benefit of the first approach is that we would have only one ‘connection handler’ to deal with. (See Figure 13.12). The drawback is that the requirements for a ‘connection’ may differ widely depending on whether we are connecting to a Visual FoxPro database or through ODBC or OLEDB, to some other data source. Having a single ‘smart’ object handle all of these disparate requirements is not good practice because it greatly increases the complexity and overhead associated with the class.