Better Alias Table DD Support

Previous: Local DD Relationships
Next: Pre and Post Find Events

It is now much easier to create, maintain, and use Alias tables and DDs.

There is no need to set alias and master attributes for the tables; it is figured out automatically.
The Studio now has an option for creating an Alias Table and an Alias DD class. If you right-click on a Table in Table Explorer, you have an option to create an Alias Table and DD.
Alias DDs are now sub-classed from their master Table’s DD. The Set Alias_File message specifies that the DD sub-class is an alias.

An alias DD is created by sub-classing its master DD, setting the Alias_File property, and adjusting other properties and events as appropriate for the alias. A simple alias DD created by the Studio would look like this:

Class cSalesPManagerDataDictionary is a SalesP_DataDictionary
    Procedure Construct_Object
        Forward Send Construct_Object
        Set Alias_File to SalesPManager.File_Number
        Set pbUseDDRelates to True
        Set pbNoCascadeDeleteStrict to True
        Set pbForeignReadOnly to True
    End_Procedure

    Procedure Update
    End_Procedure

    Procedure Backout
    End_Procedure

    Procedure Deleting
    End_Procedure
    // ... more event and method stubs
End_Class

In the above example, the alias table, SalesPManager, must already be added to the filelist. Since alias tables are normally used as parents, presumably some other DD will relate to this alias table using either Table or DD relationships.

Note that the alias DD class is sub-classed from a master class. The Set Alias_File sets the alias table number and specifies that this is an alias DD.

It is advised that alias tables use local DD relationships, which is why pbUseDDRelates is set to True. If this alias DD had parents, presumably other alias DDs, you will need to establish those relationships using local DD relates (Set Field_Related_FileField). Often alias tables do not need to refer to their parents. If this is the case, there is no need to define those relationships.

The pbNoCascadeDeleteStrict property is set to True because it is the best default for DDs that use local relates.

The pbForeignReadOnly property is set to True, which tells the DD that this record will not get changed as part of a child DDO save. Normally, these are the kinds of changes that occur inside of a child DDO’s Backout and Update events, and normally alias tables should not be changed in this way. If a change occurs, this is considered a programming error, and a runtime error will be raised. This property is set because this is the most likely default for an alias DD. You can change this if needed.

The Updating, Delete, Creating, and other events are all canceled here because any code in the super-class would most likely apply to the master table and not the alias table. Usually, you will not need to augment these events in alias DDs. If you do, you will most likely not want to forward the message.

Set Alias_File to iFileNumber

Set [Alias_File](../VdfClassRef/DataDictionary-Procedure_Set-Alias_File.md) declares this DD to be an alias DD and makes the iTable parameter the Main_File for this DD. This creates an alias DD based on this new file. Main_File is assigned iFileNumber, and the old Main_File, which is the master file, is stored and accessible via Get MasterForAlias. It also initializes the class to work as an alias, which is mostly done by calling DefineAsAlias.

Main_File must be set before the Alias_File message is set. Normally, the Main_File will have been set in the DD superclass, although it is permissible, albeit unusual, to set both the Main_File and the Alias_File in a single class (in that order).

You can only define an alias file for a DD that: 1. has a main-file 2. is not yet an alias

In other words, you can use this to sub-class regular DD classes, but you cannot use it to sub-class alias DD classes.

Send DefineAsAlias

[DefineAsAlias](../VdfClassRef/WebAndWindows/DataDictionary-Procedure-DefineAsAlias.md) is called by Set Alias_File and it sets up this DD to work as an alias. It can be augmented. If augmented, it should be forwarded.

The main purpose of DefineAsAlias is to clear any DD settings that might have been set in the master super-class that do not apply to the alias. If it clears any local DD relationships, it clears all required servers and clients and all prompt and zoom field settings.

Get IsAlias to bAlias

[IsAlias](../VdfClassRef/WebAndWindows/DataDictionary-Function-IsAlias.md) returns true if this is an alias table.

Get MasterForAlias to iFile

[MasterForAlias](../VdfClassRef/WebAndWindows/DataDictionary-Function-MasterForAlias.md) returns the file number of the master file. If this is not an alias, it returns 0.

Table Locking and Alias DDs

There is no need to set DF_FILE_ALIAS to either alias or master as the DDs will take care of the file locking as needed. You also don’t have to worry if the master DD is part of the DDO structure. If it is not, the alias DD will be treated like a normal DD.

This is done within [Reset_FileModes_For_Lock](../VdfClassRef/WebAndWindows/BaseData_Set-Event-Reset_Filemodes_For_Lock.md). If a DD is an alias, the DD will check to see if the master DD is part of the structure. If it is, it sets the alias file’s [file mode](../LanguageReference/DF_FILE_MODE_Attribute.md) to no lock (DF_FILEMODE_NO_LOCKS).

Important: If your tables are embedded (i.e., table locking), this requires that [Smart_FileMode_State](../VdfClassRef/WebAndWindows/BaseData_Set-Property-Smart_Filemode_State.md) be set to True, which is the default and is rarely changed. If you do not use smart-file mode, you must set the [DF_FILE_ALIAS](../LanguageReference/DF_FILE_ALIAS_Attribute.md) attributes for the master and alias table in the traditional fashion.

Why Alias Sub-classing Works

Any DD field settings set in the master super-class will be properly applied to the alias class. This might seem odd because the Field syntax applied to the super class uses the table name of the master table and not the alias table (e.g., Set Field_Xxxx Field MasterName.Field to Xxxxx).

The reason you can sub-class an existing class centers around the way the Field_Xxxxx messages and the Field parameter works. For example, Set Field_Label_Long Field SalesP.Name to “Name” is actually table agnostic. At compile time, this actually becomes Set Field_Label_Long 2 to “Name” and applies this to the DD’s file number. Therefore, the Field settings in the master superclass DD are applied to the alias table even though the table name is different. For example, if you wanted to change the alias label for ID to manager, you could use either of these syntaxes:

Set Field_Label_Long Field SalesP.Id to "Manager ID"
Set Field_Label_Long Field SalesPManager.Id to "Manager ID"

This applies to the FIELD syntax and not the FILE_FIELD syntax. Fortunately, DDs are defined using the FIELD syntax, and it all just works.

Also note that this does not apply to any code that directly uses a file.field name such as Move 0 to SalesP.Count. This kind of code most often occurs inside of your save and delete code such as Update and Backout. You should augment your alias DD to make sure this kind of code is not called.

Compatibility Issues

This type of alias DD is a new feature. Existing alias tables and alias DDs will continue to work exactly as they always did and should work side by side with the newer alias DD technology.

Any instances of tables being used as master or alias tables that do not use Data Dictionaries need to continue using the [DF_FILE_ALIAS](../LanguageReference/DF_FILE_ALIAS_Attribute.md) attribute.