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

If Locked is False and updates are allowed, the user can edit the values of an unbound column. 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. In this situation the UnboundColumnUpdated event will be raised. 

The BeforeUpdate event 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 within .NET's trappable error handler, depending on how the update was initiated. If transactions are not available, then store the original unbound column values prior to the update, then perform another update to restore these values should the bound update fail.