Name 

Description 

Accessing Field Values with a Dataset's FieldByName Method 

You can access the value of a field with a dataset's FieldByName method. This method is useful when you know the name of the field you want to access, but do not have access to the underlying table at design time.
To use FieldByName, you must know the dataset and name of the field you want to access. You pass the field's name as an argument to the method. To access or change the field's value, convert the result with the appropriate field component conversion property, such as AsString or AsInteger. For example, the following statement assigns the... more 

Accessing Field Values with a Dataset's Fields Property 

You can access the value of a field with the Fields property of the dataset component to which the field belongs. Fields maintains an indexed list of all the fields in the dataset. Accessing field values with the Fields property is useful when you need to iterate over a number of columns, or if your application works with tables that are not available to you at design time.
To use the Fields property you must know the order of and data types of fields in the dataset. You use an ordinal number to specify the field to access. The first... more 

Arranging Persistent Fields 

The order in which persistent field components are listed in the Fields editor list box is the default order in which the fields appear in a data-aware grid component. You can change field order by dragging and dropping fields in the list box. 

Associating Attribute Sets with Field Components 

When several fields in the datasets used by your application share common formatting properties (such as Alignment, DisplayWidth, DisplayFormat, EditFormat, MaxValue, MinValue, and so on), and you have saved those property settings as attribute sets in the Data Dictionary, you can easily apply the attribute sets to fields without having to recreate the settings manually for each field. In addition, if you later change the attribute settings in the Data Dictionary, those changes are automatically applied to every field associated with the set the next time field components are added to the dataset. 

Creating a Custom Constraint 

A custom constraint is not imported from the server like other constraints. It is a constraint that you declare, implement, and enforce in your local application. As such, custom constraints can be useful for offering a prevalidation enforcement of data entry, but a custom constraint cannot be applied against data received from or sent to a server application.
To create a custom constraint, set the CustomConstraint property to specify a constraint condition, and set ConstraintErrorMessage to the message to display when a user violates the constraint at runtime.
CustomConstraint is an SQL string that specifies any application-specific constraints imposed on... more 

Defining a Data Field 

A data field replaces an existing field in a dataset. For example, for programmatic reasons you might want to replace a TSmallIntField with a TIntegerField. Because you cannot change a field's data type directly, you must define a new field to replace it.  

Defining an Aggregate Field 

An aggregate field displays values from a maintained aggregate in a client dataset. An aggregate is a calculation that summarizes the data in a set of records. See Using maintained aggregates for details about maintained aggregates. 

Defining New Persistent Fields 

Besides making existing dataset fields into persistent fields, you can also create special persistent fields as additions to or replacements of the other persistent fields in a dataset.
New persistent fields that you create are only for display purposes. The data they contain at runtime are not retained either because they already exist elsewhere in the database, or because they are temporary. The physical structure of the data underlying the dataset is not changed in any way.
To create a new persistent field component, invoke the context menu for the Fields editor by right clicking and choose New field. The... more 

Deleting Persistent Field Components 

Deleting a persistent field component is useful for accessing a subset of available columns in a table, and for defining your own persistent fields to replace a column in a table. 

Displaying, Converting, and Accessing Field Values 

Data-aware controls such as TDBEdit and TDBGrid automatically display the values associated with field components. If editing is enabled for the dataset and the controls, data-aware controls can also send new and changed values to the database. In general, the built-in properties and methods of data-aware controls enable them to connect to datasets, display values, and make updates without requiring extra programming on your part. Use them whenever possible in your database applications. For more information about data-aware control, see Using data controls.
Standard controls can also display and edit database values associated with field components. Using standard controls,... more 

Displaying Field Component Values in Standard Controls 

An application can access the value of a dataset column through the Value property of a field component. For example, the following OnDataChange event handler updates the text in a TEdit control because the value of the CustomersCompany field may have changed:  

Persistent Field Components 

By default, dataset fields are dynamic. Their properties and availability are automatically set and cannot be changed in any way. To gain control over a field's properties and events you must create persistent fields for the dataset. Persistent fields let you

• Set or change the field's display or edit characteristics at design time or runtime.
• Create new fields, such as lookup fields, calculated fields, and aggregated fields, that base their values on existing fields in a dataset.
• Validate data entry.
• Remove field components from the list of persistent components to prevent your application from accessing particular columns in an underlying... more 

Removing Attribute Associations 

If you change your mind about associating an attribute set with a field, you can remove the association. 

Setting a Default Value for a Field 

You can specify how a default value for a field in a client dataset or a BDE-enabled dataset should be calculated at runtime using the DefaultExpression property. DefaultExpression can be any valid SQL value expression that does not refer to field values. If the expression contains literals other than numeric values, they must appear in quotes. For example, a default value of noon for a time field would be  

Setting Display and Edit Properties at Design Time 

To edit the display properties of a selected field component, switch to the Properties page on the Object Inspector window. The following table summarizes display properties that can be edited.
Field component properties  

Using Object Fields 

Object fields are fields that represent a composite of other, simpler datatypes. These include ADT (Abstract Data Type) fields, Array fields, DataSet fields, and Reference fields. All of these field types either contain or reference child fields or other data sets.
ADT fields and array fields are fields that contain child fields. The child fields of an ADT field can be any scalar or object type (that is, any other field type). These child fields may differ in type from each other. An array field contains an array of child fields, all of the same type.
Dataset and reference fields... more 

Using Server Constraints 

Most production SQL databases use constraints to impose conditions on the possible values for a field. For example, a field may not permit NULL values, may require that its value be unique for that column, or that its values be greater than 0 and less than 150. While you could replicate such conditions in your client applications, client datasets and BDE-enabled datasets offer the ImportedConstraint property to propagate a server's constraints locally.
ImportedConstraint is a read-only property that specifies an SQL clause that limits field values in some manner. For example:  

Working with Constraints 

Field components in client datasets or BDE-enabled datasets can use SQL server constraints. In addition, your applications can create and use custom constraints for these datasets that are local to your application. All constraints are rules or conditions that impose a limit on the scope or range of values that a field can store. 

Working with Field Component Methods at Runtime 

Field components methods available at runtime enable you to convert field values from one data type to another, and enable you to set focus to the first data-aware control in a form that is associated with a field component.
Controlling the focus of data-aware components associated with a field is important when your application performs record-oriented data validation in a dataset event handler (such as BeforePost). Validation may be performed on the fields in a record whether or not its associated data-aware control has focus. Should validation fail for a particular field in the record, you want the data-aware control... more 

Working with ADT Fields 

ADTs are user-defined types created on the server, and are similar to the record type. An ADT can contain most scalar field types, array fields, reference fields, and nested ADTs.
There are a variety of ways to access the data in ADT field types. These are illustrated in the following examples, which assign a child field value to an edit box called CityEdit, and use the following ADT structure,  

Working with Array Fields 

Array fields consist of a set of fields of the same type. The field types can be scalar (for example, float, string), or non-scalar (an ADT), but an array field of arrays is not permitted. The SparseArrays property of TDataSet determines whether a unique TField object is created for each element of the array field.
There are a variety of ways to access the data in array field types. If you are not using persistent fields, the dataset's ObjectView property must be set to True before you can access the elements of an array field. 

Working with DataSet Fields 

Dataset fields provide access to data stored in a nested dataset. The NestedDataSet property references the nested dataset. The data in the nested dataset is then accessed through the field objects of the nested dataset. 

Working with Reference Fields 

Reference fields store a pointer or reference to another ADT object. This ADT object is a single record of another object table. Reference fields always refer to a single record in a dataset (object table). The data in the referenced object is actually returned in a nested dataset, but can also be accessed via the Fields property on the TReferenceField. 

Defining a Lookup Field 

A lookup field is a read-only field that displays values at runtime based on search criteria you specify. In its simplest form, a lookup field is passed the name of an existing field to search on, a field value to search for, and a different field in a lookup dataset whose value it should display.
For example, consider a mail-order application that enables an operator to use a lookup field to determine automatically the city and state that correspond to the zip code a customer provides. The column to search on might be called ZipTable.Zip, the value to search... more 

Creating Attribute Sets for Field Components 

When several fields in the datasets used by your application share common formatting properties (such as Alignment, DisplayWidth, DisplayFormat, EditFormat, MaxValue, MinValue, and so on), it is more convenient to set the properties for a single field, then store those properties as an attribute set in the Data Dictionary. Attribute sets stored in the data dictionary can be easily applied to other fields.  

Programming a Calculated Field 

After you define a calculated field, you must write code to calculate its value. Otherwise, it always has a null value. Code for a calculated field is placed in the OnCalcFields event for its dataset. 

Setting Persistent Field Properties and Events 

You can set properties and customize events for persistent field components at design time. Properties control the way a field is displayed by a data-aware component, for example, whether it can appear in a TDBGrid, or whether its value can be modified. Events control what happens when data in a field is fetched, changed, set, or validated.
To set the properties of a field component or write customized event handlers for it, select the component in the Fields editor, or select it from the component list in the Object Inspector.
The following topics discuss using persistent field properties and... more 

Handling Events 

Like most components, field components have events associated with them. Methods can be assigned as handlers for these events. By writing these handlers you can react to the occurrence of events that affect data entered in fields through data-aware controls and perform actions of your own design. The following table lists the events associated with field components:
Field component events  

Accessing Field Values with the Default Dataset Property 

The most general method for accessing a field's value is to use Variants with the FieldValues property. For example, the following statement puts the value of an edit box into the CustNo field in the Customers table:  

Defining a Calculated Field 

A calculated field displays values calculated at runtime by a dataset's OnCalcFields event handler. For example, you might create a string field that displays concatenated values from other fields. 

Using Default Formatting for Numeric, Date, and Time Fields 

Delphi provides built-in display and edit format routines and intelligent default formatting for TFloatField, TCurrencyField, TBCDField, TFMTBCDField, TIntegerField, TSmallIntField, TWordField, TDateField, TDateTimeField, TTimeField, and TSQLTimeStampField components. To use these routines, you need do nothing.
Default formatting is performed by the following routines:
Field component formatting routines  

Setting Field Component Properties at Runtime 

You can use and manipulate the properties of field component at runtime. Access persistent field components by name, where the name can be obtained by concatenating the field name to the dataset name.
For example, the following code sets the ReadOnly property for the CityStateZip field in the Customers table to True:  

Creating Persistent Fields 

Persistent field components created with the Fields editor provide efficient, readable, and type-safe programmatic access to underlying data. Using persistent field components guarantees that each time your application runs, it always uses and displays the same columns, in the same order even if the physical structure of the underlying database has changed. Data-aware components and program code that rely on specific fields always work as expected. If a column on which a persistent field component is based is deleted or changed, Delphi generates an exception rather than running the application against a nonexistent column or mismatched data. 

Converting Field Values 

Conversion properties attempt to convert one data type to another. For example, the AsString property converts numeric and Boolean values to string representations. The following table lists field component conversion properties, and which properties are recommended for field components by field-component class:  

Dynamic Field Components 

Dynamically generated field components are the default. In fact, all field components for any dataset start out as dynamic fields the first time you place a dataset on a data module, specify how that dataset fetches its data, and open it. A field component is dynamic if it is created automatically based on the underlying physical characteristics of the data represented by a dataset. Datasets generate one field component for each column in the underlying data. The exact TField descendant created for each column is determined by field type information received from the database or (for TClientDataSet) from a... more 

Working with Field Components: Overview 

Field components represent individual fields (columns) in datasets. You can use field components to control the display and editing of data in your applications.
Field components are always associated with a dataset. You never use a TField object directly in your applications. Instead, each field component in your application is a TField descendant specific to the datatype of a column in a dataset. Field components provide data-aware controls such as TDBEdit and TDBGrid access to the data in a particular column of the associated dataset.
Generally speaking, a single field component represents the characteristics of a single column, or field,... more 

Controlling and Masking User Input 

The EditMask property provides a way to control the type and range of values a user can enter into a data-aware component associated with TStringField, TDateField, TTimeField, and TDateTimeField, and TSQLTimeStampField components. You can use existing masks or create your own. The easiest way to use and create edit masks is with the Input Mask editor. You can, however, enter masks directly into the EditMask field in the Object Inspector.