>Can anyone please tell me on what should I take note on creating a Multi-user program?
>
>The database, the form, coding...etc things that makes it different from creating a single user program.

Hi Tan! By the way, is Tan your first name? (I just want to make sure I am referring to your properly). Anyway...

Multi user programming basically adds the following bit of complexity to your application. You want your application to allow multiple people access to the information at the same time. So, here's what this means: When user A is editing a customer, user B should be able to edit customers as well. So, there are a few rules we get to up front.

RULE 1. Allow multiple user access to the tables at the same time.

The way you handle RULE 1 is by opening your tables in SHARED mode. Basically, VFP can open a table in two different ways. EXCLUSIVE (which means only that user can even look at the table) or SHARED (which means many people can open the table at the same time).

If you want to try this, open VFP twice on your desktop. Open a table EXCLUSIVE in one instance of VFP and then try to open the same table in the second instance. You'll see that you cannot open the table in both instances. On the other hand, if you open the tables in SHARED mode, you will be able to open the tables in both instances.

Syntax:

USE {TableName} EXCLUSIVE && Opens table exclusively
USE {TableName} SHARED && Opens table in shared mode

SET EXCLUSIVE ON  && Means that tables opened without the EXCLUSIVE or
                  && SHARED keywords are opened EXCLUSIVE

SET EXCLUSIVE OFF && Means that tables opened without the EXCLUSIVE or
                  && SHARED keywords are opened SHARED

OK, so now we have the ability to open the table by multiple people. The next issue comes with changing information. Clearly, we have to manage two people changing the same information. Well, here's how it works. I want a user to be able to modify the information on a record. The question is, while this user is modifying a record, can another access the record for modification too?

Well, let's map out the answers as follows. Assume that we are dealing with the customer table and the customer table has customer name and address information in addition to a field called

nTotalSales

which has total sales for the customer. Now, I have one user changing customer information (this user got there first) and another creating an invoice.

If the answer to my question above is NO (i.e., only one user can access a record for modification), the user creating the invoice will not be able to complete the process because the customer record cannot be modified while the first user is modifying it.

Let me take it further. Assume the first user starts modifying the customer record and then goes out for a four hour, 8 martini lunch. All this time, noone can access this record.

In this case, it would seem to me that the answer to my question is YES, more than one user can modify a record at the same time. Sometimes, you may ask this question and get a NO. That's a perfectly valid answer sometimes.

OK, let's translate this to another general rule:

RULE 2. Only lock out a portion of data for as long as you need to, not one second more.

OK, how do we manage this in Visual FoxPro. We use something called BUFFERING. Here's how buffering works (for all intents and purposes):

When you are working with a buffered record or table, VFP copies the information in the table into a "temporary" area called a buffer. You are modifying the buffer, not the actual table on disk. When you are done with your editing, you update the table on disk using the TableUpdate() function. If you need to cancel your changes, you can do so with the TableRevert() function.

There are two basic kinds of buffering: Optimistic and Pessimistic. Optimistic buffering means that while one user modifies information, another user can modify it too. Pessimistic buffering only allows one user to modify the information at any one time.

You set buffering on the form properties and on the cursors in the data environment.

An issue to bear in mind

An update conflict occurs when one user modifies data and another user modifies the same data and saves it before the current user saves changes. This only occurs with optimistic buffering. In this case, TableUpdate() will fail (and return .F.). You can figure out why the tableupdate() failed using AERROR().

Look into the OLDVAL() and CURVAL() functions. You also need to look into GETNEXTMODIFIED() (if you are table buffered) and GETFLDSTATE().

I am sorry that I am leaving these issues unexplained at this point but Imy fingers are tired. If you need help, please holler and I will go into the issue of handling update conflicts (and any other issue you need) in more depth.