Other DDF Manipulations

The methods detailed in this section can be used to handle DDFs for various other purposes.

Securing DDFs with an Owner Name

You can secure DDFs with an owner name. Two methods are provided to deal with this possibility:

DdfSetOwner. This method sets the current working DDF owner name in the ActiveX memory image (i.e., all DDF file operations will use this owner name). If RefreshLocations is True, this owner name will be applied to the DDFs themselves using the previous DDF owner name for access when making this call. This method does not affect the OwnerName property, which is used only in the context of the data file.

DdfTestOwnerName. You can use this method to set the working DDF owner name and determine the permissions it will allow.

See ActiveX Method Reference for more information on these two methods.

Deleting Existing Field and Index Information

DdfClearFields and DdfClearIndexes provide a quick and convenient way for you to wipe out the existing field and index information for the current table.

Note
If RefreshLocations is True, these changes will be written to the DDFs, so use with caution.

Forcing Comments with Persisted DDF Memory Image

DdfGetComments. This method has a very limited use. If RefreshLocations is False, the persisted memory image will be read when opening a table rather than the DDFs. However, the persisted memory image does not contain comment information. DdfGetComments ignores RefreshLocations and thus you can use this method to force the ActiveX to get comment information to go with persisted DDF information.

Methods with Wide-Ranging Effects

Finally, the following two methods have wide-ranging effects on the DDF handling operations:

DdfTransactionMode. If this method is True, all DDF handling functions that are requested to write directly to the DDFs will do so within the scope of a transaction. This means that if one part of the write fails, all of it will fail, preventing a busted relation between, for example, FIELD.DDF and INDEX.DDF.

DdfKeyUseIndexDDFOnly. This method forces the control to use INDEX.DDF only when it is set to True. Normally, the ActiveX will augment the DDF information with the index information stored in the file itself (as given in the status buffer); this makes the control more robust when dealing with incorrect INDEX.DDF entries. However, this behavior also makes it difficult to use the control to repair incorrect INDEX.DDF entries, since the actual DDF information is partially overwritten when the file is opened.

If DdfKeyUseIndexDDFOnly is set to True, the control will not overwrite any of the index information with the index information in the status buffer. This means that if there is an incorrect INDEX.DDF entry, the control will be unable to navigate through the file, but will reflect the current state of the DDF. This makes it easier to diagnose and repair the incorrect entry.