A record is a collection of data about a single entity, such as an account or a customer, stored in a table (a row of the table).
A D V E R T I S E M E N T
A record consists of a group of contiguous columns (sometimes called fields) that contain data of various types. A set of records selected from a data source — often called a result set in database terms — is called a recordset in MFC. For more information, see Recordset (ODBC).

A database schema describes the current structure of the tables and database views in the database. In general, wizard-generated code assumes that the schema for the table or tables accessed by a recordset will not change, but the database classes can deal with some schema changes, such as adding, reordering, or deleting unbound columns. If a table changes, you must manually update the recordset for the table, then recompile your application.

You can also supplement the wizard-generated code to deal with a database whose schema is not entirely known at compile time. For more information, see Recordset: Dynamically Binding Data Columns (ODBC).

Information about the tables in a data source can include the names of tables and the columns in them, table privileges, names of primary and foreign keys, information about predefined queries or stored procedures, information about indexes on tables, and statistics about tables.

For more information, see Data Source: Determining the Schema of the Data Source (ODBC).

The concept of a transaction was developed to handle cases in which the resulting state of the database depends on the total success of a series of operations. This could come about because successive operations might modify the results of previous operations. In such cases, if any one operation fails, the resulting state could be indeterminate.

To solve this problem, transactions group a series of operations in such a way that the integrity of the final result can be assured. Either all the operations must succeed and then be committed (written to the database) or the entire transaction fails. The cancellation of the transaction is called a rollback. Rollback allows a recovery from the changes and returns the database to the pretransaction state.

For example, in an automated banking transaction, if you transfer money from account A to account B, both the withdrawal from A and the deposit to B must succeed to process the funds correctly, or the whole transaction must fail.

A transaction must have ACID properties, which stand for the following:

• Atomicity A transaction is an atomic unit of work and executes exactly once; either all the work is done or none of it is.
• Consistency A transaction preserves the consistency of data, transforming one consistent state of data into another consistent state of data. Data bound by a transaction must be semantically preserved.
• Isolation A transaction is a unit of isolation and each occurs separately and independently of concurrent transactions. A transaction should never see the intermediate stages of another transaction.
• Durability A transaction is a unit of recovery. If a transaction succeeds, its updates persist, even if the system crashes or is shut down. If a transaction fails, the system remains in the state previous to committing the transaction.

You can support transactions in OLE DB (see Supporting Transactions in OLE DB) or ODBC (see Transaction (ODBC)).

A distributed transaction is a transaction that updates distributed data, that is, data on more than one networked computer system. If you want to support transactions over a distributed system, you should use the Microsoft .NET Framework rather than the OLE DB transaction support.

For information about transactions in the Microsoft .NET Framework, see Processing Transactions in the Windows Software Development Kit (SDK).

This section applies only to the MFC ODBC and DAO classes. For information about OLE DB record views, see COleDBRecordView and Using OLE DB Record Views.

To support form-based data-access applications, the class library provides class CRecordView and class CDaoRecordView. A record view is a form view object whose controls are mapped directly to the field data members of a recordset object (and indirectly to the corresponding columns in a query result or table on the data source). Like their base class CFormView, CRecordView and CDaoRecordView are based on a dialog template resource.

You can do form-based data-access programming with class CFormView, but CRecordView and CDaoRecordView are generally better classes to derive from. In addition to their CFormView features, CRecordView and CDaoRecordView:

• Provide dialog data exchange (DDX) between the form controls and the associated recordset object.
• Handle Move First, Move Next, Move Previous, and Move Last commands for navigating through the records in the associated recordset object.
• Update changes to the current record when the user moves to another record.

For more information about navigation, see Record Views: Supporting Navigation in a Record View.

When you use Add Class to map the controls in a record view's dialog template resource to the fields of a recordset, the framework manages data exchange in both directions — from recordset to controls and from controls to recordset. Using the DDX mechanism means that you do not have to write the code to transfer data back and forth yourself.

DDX for record views works in conjunction with:

• RFX for recordsets of class CRecordset (ODBC).
• DFX for recordsets of class CDaoRecordset (DAO).

Although they differ in implementation, at the interface level RFX and DFX are very similar data exchange mechanisms. The DAO version, DFX, is modeled closely on the earlier ODBC version, RFX. If you know how to use RFX, you know how to use DFX.

RFX and DFX move data between the current record of the data source and the field data members of a recordset object. DDX moves the data from the field data members to the controls in the form. This combination fills the form controls initially and as the user moves from record to record. It can also move updated data back to the recordset and then to the data source.

The following figure shows the relationship between DDX and RFX (or DFX) for record views.

Dialog Data Exchange and Record Field Exchange

For more information about DDX, see Dialog Data Exchange and Validation. For more information about RFX, see Record Field Exchange (RFX).

The following table shows what you typically must do to work with a record view and what the framework does for you.

Form-based programming is only one approach to working with a database. For information about applications using some other user interface, or no user interface, see MFC: Using Database Classes with Documents and Views and MFC: Using Database Classes Without Documents and Views. For alternative approaches to displaying database records, see classes CListView and CTreeView.

You can create your record view class with the MFC Application Wizard. If you use an application wizard, it creates the record view class and a dialog template resource for it (without controls). You must use the Visual C++ Dialog editor to add controls to the dialog template resource. On the other hand, if you use Add Class, you must first create the dialog template resource in the Dialog editor and then create the record view class.

This information applies to both CRecordView and CDaoRecordView.

To create your record view with the MFC Application Wizard

To design your form

To create your record view class