Lesson 5 – File/Field Flag Inconsistencies
Scenario
In this lesson, you have a Btrieve file with flags set for a field that are inconsistent with the SQL column flags set in the table definition.
Goals
The goal is to open the file with DDF Builder and see if DDF Builder makes any updates to the definitions. You will inspect any changes that DDF Builder implements and discuss changes, if any, that are needed to fix the flag inconsistencies.
What You Need to Know
For this lesson, used the file named FLAGS.MKD. This file resides in a folder named Tutorial2. Assuming you installed using the default installation locations, this folder is located at:
<Application Data>\DDFBUILDER\TUTORIALS\TUTORIAL2
This folder is part of the Tutorial2 database.
*Note: You must have a Data Source Name (DSN) that points to this database in order to access the data in this tutorial. If you have not yet created this DSN, refer to Create Data Source Names (DSN).
Open the Btrieve File
You should have DDF Builder already running from the last lesson. If not, begin by starting DDF Builder.
1
2
3
4
The Table Definition Editor opens and displays the following message:
This message tells you that DDF Builder analyzed your existing table definitions and found problems with those definitions. As a result of this, DDF Builder had to make some modifications to open and display the existing table definitions.
5
Click OK to clear the message and display the table definition.
*Tip: For a complete list of possible definition errors, refer to Table Definition Errors.
Look for Inconsistencies
Begin by looking at the DDF Builder interface to review the inconsistencies with which you are dealing. First look at the grid data view and the Definition Errors window.
The grid data view of the Table Definition Editor shows your existing table definition with the modifications that DDF Builder made.
*Note: DDF Builder changes are not automatically saved. Any modifications made by DDF Builder must be saved.
For this lesson, DDF Builder does not give any visual indications as to the columns that need attention. No unknown column indicators suggest that any of the fields have been altered.
*Tip: For more information on the attributes in the grid data view, refer to Field Attributes in Grid Data View.
A list of the issues DDF Builder detected and changed display in the Definition Errors view.
Now, take a moment to look at the original table definition. The original table definition, before DDF Builder made any changes, is available from the Original Definition view.
Before you proceed with the details of the inconsistencies in the table definitions, make sure that you understand the definition errors reported by DDF Builder.
Understanding the Errors
The Definition Errors view tells the following:
The Definition Errors list one problem:
The error indicates a Case flag set on a SQL column but the flag was not set on the corresponding Btrieve segment. Since DDF Builder does not change the Btrieve file, the SQL table has been modified to match the specifics of the Btrieve file. To make certain this is the situation, compare the current table definition to the original definition.
The definition error lists the problem is with the lastName column’s Case setting. If you compare the lastName fields of the current and original table definition, you can quickly see the difference.
From the comparison, you can determine the following:
The original, or existing, definition did not have the Case flag set on the lastName field.
The current definition (updated by DDF Builder) does have the Case flag set on the lastName field.
DDF Builder made changes based upon the Btrieve file. Remember, DDF Builder cannot change your Btrieve file, only the table definitions that determine the structure of your Btrieve file. That being the case, DDF Builder changed the original definition (without the Case flag) to allow for the lastName field to use the Case flag.
*Note: The lastName field is used as an index. You cannot clear the Case flag from the lastName field because it is an index.
Accept or Reject Changes
You have determined the cause of the definition error and understand what changes DDF Builder made. Now you need to either accept or reject the changes that DDF Builder made to the table definition.
If the changes DDF Builder made are incorrect, you would reject the changes and create a new table definition from scratch, since you are unable to change the Case setting for a field marked as an index.
However, for the purpose of this lesson, accept the changes that DDF Builder made. You want the Case flag set on the lastName field.
Save the Table Definition
Now that you have reviewed the table definition error and changes, you must save your work in order for the change to take effect. Before you save your work, take one final look at the table definition. Your data grid view should look similar to the following:
Take a quick glance and verify that all of the Btrieve Types are defined, there are no undefined fields remaining and every byte is accounted for. You can now save your table definition.
1
From the menu bar, click FileSave to save the table definition.
Your updated table definition is now saved to use the Case flag setting on the lastName field.
Conclusion
This lesson introduced you to how DDF Builder handles flag settings that differ from the Btrieve file and the existing table definition. It showed you how the grid data view and the original definitions view can be used to compare changes made by DDF Builder. This lesson also showed you that altering a field set as an index is not allowed in DDF Builder. Strategies for rejecting or accepting the changes made by DDF Builder were also discussed.