Updating unbound columns

In most cases, you will want unbound columns to be read-only, as the values are derived from other data in the grid. In these cases, you should set the Locked property of the column to True.

If Locked is False and updates are allowed, the user can edit the values of an unbound column, even if the underlying Recordset is not updatable. However, if the underlying Recordset is not updatable, the unbound column's Locked property will automatically be set to True at run time, regardless of the design time setting in the property pages. Therefore, for editing to be allowed, you must set the unbound column object's Locked property to False at run time using code.

If editing of an unbound column occurs, the row will be marked as dirty (a pencil icon will be shown in the record selector column) and the update sequence will be performed as usual. However, the grid does not know what to do with the modified data, since there is no database field in which to store it. Therefore, you must put code in the BeforeUpdate and AfterUpdate events (or BeforeInsert and AfterInsert for AddNew operations) to properly store the edited values. These values may be stored in any manner desired, including another database table.

BeforeUpdate can be used to cancel the update operation. Therefore, if the unbound column is to be used in cooperation with another database, the update of the unbound column should be performed in BeforeUpdate. If the operation fails, then the event should be canceled. However, if the operation succeeds, then the bound update should be allowed to proceed. The bound update may then fail, hence any database actions associated with unbound columns would best be handled on a transactional basis.

If the bound update succeeds, the AfterUpdate event is fired, and the unbound column transaction should be committed. If the bound update fails, the unbound column transaction should be rolled back in either the grid's or the Data control's Error event, or within a trappable error handler, depending on how the update was initiated. If transactions are not available, then you must store the original unbound column values prior to the update, then perform another update to restore these values should the bound update fail.