Adding Changes To A Working Application

"Ok, now I have made a design change, what do I need to send to the end user?"

A previous article covered what information is included in each file type. This article will show how to apply that information to solve a real world problem. A common issue for many developers is how to send design changes to an end user. It is a frequent topic on the user's forum. It is normally impractical to send a complete new program, since data has probably already been entered and can't be overwritten. There may be a need to send the change through email and file sizes may be limited. When you know which file contains a design change, you can make a more educated decision about what files need to be sent to the end user. The following concepts are intended for standalone and server installations that contain all of the working data.

A critical step in the whole process is keeping detailed information about what changes are being made. The developer should keep a list of every change made, including which table is associated with the change, what element is changed (field rule, form design, index definition, field name, etc.), and a description of the change. Then it is only necessary to update the files related to these elements, not the complete program. Many developers use some type of build or version number to keep track of modifications. This number can be saved as a global variable or in a table that can be accessed by the user. This allows the developer to keep track of which version the end user has loaded and which modifications have already been completed.

Changes to Tables

What happens when data is added to a table or existing data is modified? This scenario is normally only a concern for a developer when there are tables that are common for all users, like zip code tables, that may need updated and corrected.

A number of files are effected when data is changed. If we make changes in a customer file called "customers", the "customers.dbf" (and "customers.ftp", if there is a memo field in the customers table) files will change. If these changes must be transferred to another standalone system, you should copy these files. The index file, "customers.cdx", will be changed if a record has been added, a record deleted, or a change made in any field that is included in an index definition. Here, you have a couple options. You can copy the new cdx file as well or just run an update indexes operation if the index definitions have not changed. This will update the indexes using the new data and may be preferable if the cdx file size is large. A script can be easily written to automate this process.

If the change is made from within a set, the proper solution is to copy the dbf, cdx, and ftp (if it exists) for each table in the set, since it may be difficult to establish which table has changed. Only the individual table data needs copied, since the set definition files do not contain actual data.

What happens when data is deleted? Common practice in modern database design is to only "mark" a record as deleted when the user wants to remove a record. The record still exists, but is not easily accessible or visible. A "pack" or "compact" operation is conducted to actually permanently remove the record. The term "pack" is used in Alpha 5 to describe the erase operation. In other types of databases, the term compact may be used. If any records are deleted, a pack operation should be run before copying any files.

The most common changes made by a developer include adding / modifying forms, browses, reports, form letters, and so on. All of these design elements are saved in the table and set data dictionaries. If a new form is added to the "customers" table, the design will be saved in the "customers.ddd", "customers.ddm", and "customers.ddx" files. To get this design change to another user, these files must be copied. If the change was made to an element attached to a set, the .set, .sem, and .sex files will change and must be copied.

When a form or other design element is modified, the original design code is marked as deleted. Since the data dictionary is really just a dbf table with a different file extension, this old code is handled just like a deleted record in the data tables. It still exists as part of a memo field, but is not accessible. As more and more changes are made, the size of this deleted code can get very large. Just like the pack command is used to erase deleted data records, Alpha has a compact command to remove unused information in the data dictionaries. The compact operation should always be run when any design changes have been made. The Alpha database compact command from the control panel will "compact" every data dictionary attached to the database. It also updates all of the indexes. There is an Xbasic compact command (dictionary.update()) that can be used to compact a single data dictionary. When a data dictionary is compacted, it's modified date will change to the current date and time. Some developers see this new date and assume the file must have been modified. However, if a data dictionary had not been changed since the last compact, nothing is removed and the information is exactly the same as before, even though the date has changed. Your detailed list of changes will show you which table data dictionaries have really changed. These are the only ones that need to be copied. In our example, only the "customers.ddd", "customers.ddm", and "customers.ddx" files must be copied to the other user if the only change was a new or modified form in the "customers" table.

Table structural changes can get more complicated. If a field is renamed, this will effect a number of elements. First, the actual dbf file will change since names are saved in the table definition. If the table contains any long field names (over 10 characters) then the data dictionary files will also change. The dbf file can just be copied if the developer system has exactly the same data as the end user. However, this is rarely the case. A common solution is to create a method to copy the existing user data to a temporary file, copy an empty version of the dbf file with the new structure, and then append the existing data back to the new table definition. The same scenario exists if a field is added or deleted.

Changes to Indexes

When an index expression is changed, an index is added or removed, or an index renamed, these structural changes will be saved in the table's cdx file. A common way to get these changes to an end user is to make the changes to a development copy of the table and then empty the contents of the table. This will create an empty index file. Copy the empty cdx file to the end user and run an update indexes operation discussed earlier in the article. This will rebuild all of the indexes with the user's existing data. If the index uses long names (over 10 characters), this information is saved in the table data dictionaries. Therefore, if there are any long names in the index definitions, the data dictionaries must also be copied when an index is modified.

Changes to the Database Common Elements

The database data dictionary files (.alb, .alm, .alx) contain the common elements that can be used by many tables, such as custom menus, custom toolbars, global scripts, and user defined functions. The database data dictionaries will change if you create or modify a custom menu. The same applies to custom toolbars, user defined functions, and global scripts. The dictionaries should be compacted since they behave just like the table dictionaries and leave old information in the file until the compact operation is completed. You can then copy the database data dictionary files. In addition, you must copy the data dictionary for any table that uses these common elements. If our example "customer" table form has a custom menu and is attached to a database called "sales", then me must save the "sales.alb", "sales.alm", and "sales.alx" files as well as the "customers" data dictionaries. Some developers create custom colors for their application for special effects. These custom colors are also saved in the database dictionaries.

The Database .adb File

The database adb file changes only under specific conditions. It will change if any tables or sets are added or detached from the database. If will also change if certain database properties are modified, such as specifying a form to open on startup and all settings other than custom colors. This file also contains path information, which is normally not an issue if all tables and related files are saved in the database directory.

Other Stuff

Developers frequently have other files that are used by a database. These include bitmaps for forms and buttons, the occasional batch file, help files, and other programs like file compression programs that may be used by the database. Don't forget to copy these also. A good rule is to embed bitmaps if possible to eliminate problems when files are copied, but this is not always practical. You may link a logo bitmap that can change and you don't want to be locked into an existing design. If this changes, it must be included in any files copied.

Summary

You can make good decisions about what files to copy to update an end user program if you keep close track of modifications and understand the file structures. Some developers send all of the table and database data dictionary files to the end user, but this is not always required. If the change affected only a few tables or sets, just send the dictionaries for those changed elements.

But there is one more consideration. How do you transfer these files to the end user? Some developers just copy the changed files to a CD and let the end user copy these to their computers. But this creates a problem since a CD is read only. The read only attribute must be turned of after the files are copied. A better solution is to use a self-extracting file compression utility to compress the changed files. This not only reduces size, but when the files are uncompressed, they will not be read only regardless of the medium used for transfer. If you only include the changed files, this can frequently be sent by email.
[PRINTER FRIENDLY VERSION]