An Introduction to Client-Server Development in Visual FoxPro

An Introduction to Client-Server Development in Visual FoxProby Scot Becker

Introduction

Note: This article originally appeared in the Virtual FoxPro Users Group October newsletter and is re-published here with permission of the author and the Virtual FoxPro Users Group.In this article, I will explore the many facets of client-server development with Visual Foxpro. Please note, this article was written under the assumption that not many significant changes or enhancements were made to the Client-Server structure of Visual FoxPro version 5.0. Obviously, this article will leave out many complexities that come with programming on a server. I will try to cover the basics, and leave the reader to further explore this development technique as his/her situation merits. I will use Visual FoxPro version 3.x and Microsofts SQL Server version 6.x for all of my examples. However, most of these examples can be easily transposed to whatever server platform you have.

Benefits of a Data Server versus a File Server

Network Input/Output(I/O):

In a file server architecture, the client requests a portion of a file that is then sent to the workstation for processing. The workstation then has to perform all data selection, processing, and modification to the file before any changes are sent back to the file server for reconciliation. In contrast, a data server acts on a request for data from the data file. The data server then sends the requested data back to the client, which acts like a dumb terminal. If any modifications are made to the data, the client requests an update to only the modified data. This reduces processing time and network I/O.

Client Architecture:

A few years ago, a 486DX66 with 4 to 8 Megabytes of RAM was a high powered workstation. Today, this would be considered a low end workstation. However, those slower machines are still capable of running a well-designed Client-Server application (with additional memory so Visual FoxPro can run more efficiently). How often will your company or client upgrade their machines? Relatively speaking, a Pentium 120 will soon become a Delta 88, but it will still be able to run Client Server applications. Even if you have a network with excellent throughput, a Client-Server application can still benefit by distributing the load so that you can support slower (and additional) client workstations. Another advantage is compatibility with third party products. Not all products, Decision Support Systems in particular, will support or work efficiently with Visual Foxpro. However, most products will support a SQL Server architecture.

Performance:

Query speed will be about equal for both Client-Server and Data-Server applications. However, data entry and processing might fair a little better in a Client-Server application. For example, a company has a customer support department of over 50 users who are constantly viewing and updating customer records one at a time. Performance in this case will almost certainly fair better under a SQL server, which is optimized to handle this kind of overhead.

Data Size:

Another advantage of a data server, a primary advantage for some, is data size. Currently, Visual Foxpro can only support a Table size of 2 Gigabytes. Any more than that, and you will have to break your data structure apart. Microsoft SQL Server will support a table size of up to 8 Terabytes.

Security:

Your data is also far more secure on a data server. DBF file formats are well known, and nothing (besides encryption tools) is to stop someone from also accessing your data from another application. On the other hand, nothing can happen on a SQL Server without a valid user name and password. Furthermore, the database owner has to grant permissions for users to even see his/her tables and can also limit a user to certain columns or rows (via a view). Combining SQL Sever security with the robustness and security features of Windows NT, your sensitive data is quite secure.

Recoverability:

Another advantage of a data server is recoverability. In the event of an unexpected shutdown, the validity of the data file could become corrupt on a file server. On a SQL Server, all transactions are logged. At startup, SQL server checks the transaction log against the data residing in the tables. It will apply any changes that are not reflected in the tables, or it will rollback any uncommitted transactions from the tables.

Other Features:

Lastly, SQL Server will support all the referential integrity and other database perks that Visual FoxPro does (in some cases, better than Visual FoxPro); on-line backup (you can backup your data while users are on the system), and a fuller SQL syntax (outer joins; correlated subqueries, inserts, updates, and deletes; and fuller wild card support). SQL Server is also fully integrated with Windows NT as an NT service.

Utilizing Remote Views

The quickest way to apply your FoxPro application against remote data is to utilize Remote Views. A Remote View is just like a Local View; It is nothing more than a CURSOR that is supplied with data from a SELECT statement. Like Local Views, Remote Views can either be updatable or read only. The only difference between a Remote View and a Local View is that a Remote View is supplied with data from a remote data source.

First, you must set up an Open Database Connectivity (ODBC) connection to your server via the ODBC administrator. ODBC is basically just a translation layer between Visual FoxPros version of SQL and your servers version of SQL (the versions may not always be the same).

You should then setup a connection between Visual FoxPro and your declared ODBC data source. You do not need to use a connection but you will have to supply login ID and password each time you open, modify, or requery the remote view. Creating a connection is easy. From the Data tab, select Connections and then select New. Select your ODBC data source and add your user ID and password. Supply the amount of login information that you wish, but remember, if you do not completely specify the login information, the user will be prompted to enter the missing information. One problem with the Connection Designer is the fact that it does not mask your password. This is only an issue if you do not have a secure development environment and you do not properly distribute your application.

The quickest way (at this point) to create a Remote View would be to use the Remote View Wizard. You can either base your view on the previously defined ODBC data source, or on your connection. Again, if you choose the data source, you will always be prompted for your User ID and Password, but this will not happen if you completely setup your connection. The rest of the Remote view wizard is self-explanatory.

Tip: If you want all of the tables fields in your view, you may want to explicitly choose all of your fields one at a time rather than using the button that selects them all at once. A fast way to do this would be to first select all fields, de-select one field, and then re-select it. The reason for this is that Visual FoxPro will implement the select all button as SELECT * FROM.... rather than SELECT field2, field2,... FROM..... This will be important if, at a later date, you add field to the remote table that you do not want reflected in the view.

Next, open your Remote View in the View Designer and modify any of the selection and filtering criteria (I think you will find that the Wizard is not always adequate in this area). Then select the Update Criteria tab. First, select a key field (the column under the key symbol) for your view. Visual FoxPro will not let you write to your view without specifying a key (also, note that a key can be more than one value). From there, you can select the fields that you want to update (the column under the little pencil); If it is all of the views fields, you can select the Update All button. The Update All button will not automatically select the key to be updatable because, in some situations, you do not want the key to be modified. If you want your key fields to be updatable, you will have to explicitly select them. Then select Send SQL Updates.

Tip: All of these settings can also be specified with the DBSetProp() function.To set up a buffering scheme, issue a SET MULTILOCKS ON, and set the buffering scheme with CursorSetProp(). I would recommend scheme 3, Optimistic Row Buffering, for now, but more on that later. Now open your view, and either BROWSE it or use a form to modify some of the data. All of your changes are held in the buffer and have not been sent back to the remote server yet. To update the remote table, you must issue a TableUpdate() such as:

IF TableUpdate(.T.) .T.

=MessageBox(Update Failed, 0, Error)

=TableRevert()

ENDIF

The first parameter in the TableUpdate() function specifies that all updated rows in the buffer will be sent to the server, and the server will attempt to update them all. If any of the individual updates fails, due to a trigger, constraint failure, etc., the rows that are valid will be updated, and those that are not valid will be reverted to their original values via the TableRevert() function.

The minimum to write a Client-Server application has been completed. However, Performance will be inadequate. The first step towards optimization is the parameterized view. This is implemented by a filtering (WHERE) clause except the expression is evaluated against a memory variable. An example is if you only want to look at a specific record (or record set), do the following:

SELECT..... WHERE CustomerNo = ?lnCustNo

Before you open the view, assign lnCustNo a value. Note: Visual FoxPro will also prompt you for the value of lnCustNo if it is not defined from a previous assignment.

Buffering:

Visual Foxpro supports five styles of table buffering all of which are designated with integer values.

No Buffering (1): This is the default.

Pessimistic Row Buffering (2): In this scheme, the record is locked once it is selected for editing and stays locked until the record pointer is moved or a TableUpdate() is issued.

Optimistic Row Buffering (3): In this scheme, the record is locked only while a TableUpdate() is issued, and stays locked until the record pointer is moved, or until the TableUpdate() is completed.

Pessimistic Table Buffering (4) and Optimistic Table Buffering (5): These are just like their respective row buffering schemes except the entire table is locked until the record pointer is moved or a TableUpdate() is issued.

I would recommend option 3, Optimistic Row Buffering (Also note that Pessimistic locking methods are not supported by Microsoft SQL Server).

Other Useful Functions:

CurVal() and OldVal() will return the values of the buffer and actual table data respectively.

GetFldState() returns the status of a field (appended, modified, deleted, etc.).

GetNextModifed() returns information about modified fields.

CursorGetProp() returns the current property values of the cursor.

AError() returns information about the last error and can be used in building your error handler.

Refresh() refreshes your view with the modified data.

ReQuery() requeries the remote source.

Remote View Tips:

In addition, there are some tweaks to the Remote View that may prove to be of value. You can find these under the SQL WHERE Clause Includes section on Update Criteria tab of the View Designer, and the Advanced Options selection of the Query menu pad (For Example: how many records to fetch at a time, fetching memo fields, and connection sharing). The option of particular interest would be connection sharing. Microsoft SQL Server allocates memory for each connection (about 4 Megabytes for 100 connections). Connection sharing basically sets all views to one connection. As long as you are not doing simultaneous fetches, you will never notice the difference to your application except in increased query execution speed.

Tip: You can use DBGetProp(), DBSetProp(), SQLGetProp(), and SQLSetProp() to view and alter all of these settings.Using SQL Pass-Through

The main difference between Remote Views and SQL Pass-Through functions is that you execute everything using function calls. Your SELECT statement is merely a string parameter. Result sets are returned to CURSORs named SQLResult, SQLResult1, SQLResult2, etc. You will still want to use parameterized queries and all of the tips previously discussed (setting query properties, updatable fields, keys, etc.). The most apparent benefit is that you can execute stored procedures. Your command, for example in ISQL, the query tool that ships with Microsoft SQL Server, EXECUTE(StoredProcedure), is a passed to the server via the SQLExec() function that has the name of the stored procedure in the string parameter.

Another configuration option to mention here is a connection property: Synchronous and Asynchronous Processing. With Synchronous Processing, you have to wait for the query to finish executing before control is returned to Visual FoxPro. This is fine for quickly executing statements, but longer queries where you may want some control of the client during the query execution (for example, to use a thermometer bar) would require Asynchronous Processing.

Tip: You can also use Asynchronous Processing to prompt users during a potential runaway query.Some useful functions that have not been previously mentioned are:

SQLConnect() connects to a server using an ODBC data source, user ID , and password.

SQLStringConnect() connects to a server using an ODBC connection string.

SQLDisconnect() disconnects a connection to the server.

SQLExec() sends a SQL statement to your server for execution.

SQLCancel() cancels an executing statement.

SQLMoreResults() fetches another result set from an executing query.

SQLCommit() sends a commit transaction request to the server.

SQLRollBack() sends a Rollback Transaction request to the server.

SQLTables() returns a list of tables residing in your data source.

SQLColumns() returns a list of columns of the selected table in your data source.

Tip: The SQLTables() and SQLColumns() functions are great for building an interactive query builder.Client-Server Application Design Issues

There are design issues to review when implementing a Client-Server application.

Data Partitioning:

To minimize network traffic, you may want to partition your data. In other words, keep a portion of the data on the local LAN or client machine. Seldom changing data, such as a table of zip codes or states, are particularly good candidates for this, especially if you refer to them often. Tables that change infrequently can be stored locally provided they can be updated automatically or on a scheduled basis. For example, in a Client Server application that I developed, there was a list that changed frequently, but not on a regular basis. The solution for this was to make a scheduled update on a daily basis from the server and to provide a means to temporarily enter a new list item (until the next days scheduled update) if needed. Data items that change, but much more infrequently can be updated by a procedure in a menu command. This will introduce some administrative overhead, but if all your users (or you) have to do is click a menu option once a month (or whenever the data needs to be refreshed). This will minimize overall network I/O.

Multiple Users:

An issue that may not always come up (but it will eventually) is how to handle multiple changes to the same record. For example, two users have the same record buffered and make changes to the buffer. Then, one user completely updates the record before the second user. A regular TableUpdate() will return false for the second user if it sees that the data has changed since the buffer was first written. Which change is right? There are four approaches, which will usually vary on your particular application or data structure. First, we can assume that the current user (who may have the customer on the phone) is always right. You would then issue a forced table update by calling TableUpdate(.T. ,.T.). The second strategy would be to make the user requery the data for comparison before changing it. In this case, a TableUpdate(.T.) will return false, and you will have to issue a TableRevert(). Then, if you have a good error handler, you can prompt the user to try the change again (after they see the other users changes). The third approach would be to issue a TableUpdate(.T.) and update all the records you can, and then notify the user which update failed by utilizing the GetNextModified() function, then issue the TableRevert() function. The last option is to let the user decide which change to implement by using the GetNextModified() function, presenting the user with both options, and letting him/her chose. Then, issue the forced update (TableUpdate(.T. ,.T.)) or TableRevert() as needed.

Distributed Client-Server Architectures:

If you have a distributed (many servers or a WAN) Client-Server architecture, you will need to consider multiple sources of the same data. This can usually be solved on the server side via tools such as replication or scheduled data transfers.

Data Validation:

Generally, you want to keep all data validation rules on the server. This minimizes the burden of version control. To effectively develop this strategy, a robust error handler can trap, report, handle, and interpret ODBC errors. On the other hand, if you apply data partitioning, you will have to implement some sort of local data validation as well, whether it is via code or local table level validation.

Referential Integrity:

Referential Integrity should always be handled by the server (except for local table referential integrity, if any). SQL Server makes this task easy by using of constraints, keys, triggers, and rules; Again, you will need a robust error handler.

Security:

Data security should always be handled by the server. User rights can be as specific or as general as you like through the use of stored procedures, permissions, and views. If you want to secure any local data, you will need to account for this in your application, but all sensitive data should always be kept on the server.

Remote Views vs. SQL Pass-Through

An effective application will make good use of both Remote Views and SQL Pass-Through functions. For data entry, record lookup, and static queries (with a discrete set of parameters), Remote Views are easier to implement and much more intuitive to code and debug. However, for ad hoc querying, reporting, and distributed updates (updating more that one table at a time) you will want to use SQL Pass-Through functions.

Local Data Sets:

Some effective Client-Server applications will also do large data downloads to the client machine on a regular basis, and perform queries against the local snapshot of the server data. This will minimize network traffic, but may not always result in accurate query and report results. If the query does not have to be entirely accurate, consider this option. One large download once a day may be better than many short queries all day. There is a security consideration with local downloads, in that now sensitive data may be stored on the LAN or local machine. Again, all sensitive data should always be stored on the data server.

Prototyping In Visual FoxPro:

Another thing to consider is prototyping your application in Visual FoxPro. This is a good idea for many reasons. First of all, development may occur while your server is being setup. This way, you can adjust your table structure without having to bother with the server until your architecture is more stable. Also, once your table structure is set, you can upsize (only if you have the professional version of Visual FoxPro) your table structure and your data to a Microsoft SQL Server. While prototyping, base your views from the local tables and write your code against the local views just as you would against the remote views. Once you are ready to hit the server, just change your local views to remote views and add in your Pass-Through functions.

Server Administration:

There are many server level issues to consider. These issues are neither a trivial nor always quick to solve. Backup strategies; number of users; memory; storage space; writing of triggers, rules, indexes, and constraints; keys; user and group permissions; and other administrative tasks need to be considered. Also, someone is going to have to oversee the daily maintenance of the server. You will need some good books and/or classes, time, and patience, or find someone who is capable of those administrative tasks.

Conclusion

Visual FoxPros Client-Server capabilities are, in my opinion, second to none. By utilizing the concepts discussed in this article, you can provide added value for your company or client. These skills will always be useful, and should be included in the toolbox of any serious developer. Remember, you do not need a SQL Server to practice these skills or utilize any of the techniques that I have discussed here. Any ODBC source, even Visual FoxPro databases, can act as a remote data source. Also, even if you do not plan on writing any Client-Server applications, you can still use many of the techniques discussed in this article in any multiple user environment.

The Author would like to thank (in alphabetical order) Mike Bisek, Chad Coon, and Leah Quam for their assistance in formulating this document. This document is Copyright, 1996 by Scot Becker and may not be re-printed or re-published in any format without the permission of the author and the Virtual FoxPro Users Group

This page was last modifed: undefined (this is not always available on all browsers)

Vitus@Vitus.com