Data Management

Remote Data

The client says they want to have multiple data locations for different sets of data. You say sure that’s easy and set out to create the application. You use the form designer to build the forms and use the data environment to make the data binding easy. You test the system and find out that Visual FoxPro has hard coded the location of the data files on you. What do you do? How can you have the data location be determined at runtime?
Current Work Area

Visual FoxPro has 32,767 available work areas… for each data session. Since every form or formset, toolbar, and report can have its own data session, the total number of work areas available is astronomical. Add into this object orientation with classes and event driven interfaces where the developer has very little control over what code runs and when, and you have the makings of a nightmare. How can you keep track of the current work area in this scenario?

There are situations where we need to update more than one table or cursor and the combination of the updates represents one action on the database. This action has to be an “all or none” operation that is, either all of it happens or none of it happens. For example in writing the code to save a new invoice we need to add a record to the invoice header table, add a group of records to the invoice line item table, update the balance in the customer record, and add a record to the accounts receivable table. If any of these operations fail we need to reverse the earlier ones that did succeed and make sure that none of these updates get into the data. Transactions are designed for this very purpose.
Table Update

TableUpdate() is one of the functions used very frequently when using buffering in Visual FoxPro. Version 5.0 of Visual FoxPro has enhanced the functionality of this function. This month we will look at the improvements to the TableUpdate() function.
Open or Not

Have you ever wondered if there is any benefit to opening the tables for an SQL SELECT command before you execute the SELECT? Does the SELECT use the source tables that are already open? Interesting questions.
Update Conflict Resolution

In the olden days of FoxPro 2.x we used to use indirect editing, that is editing memvars rather than the fields directly. Why did we do this? Because this gave us control over when and if the users work would be saved. The word was that editing the fields directly would make immediate changes to the file that we could not reverse easily.
Date Handling

The year 2000 sends shivers down the spine of many a database developer. Visual FoxPro developers need not worry about the turn of the century because of the date support in the product. This month we will examine the commands that provide the next millennium support as well as look into some valuable date manipulation routines.