The EX31A Program Elements

Let's take a look at the major elements in the EX31A program.

Connecting the Recordset Class to the Application

When ClassWizard generates the CEx31aSet class, it adds the CPP and H files to the project—and that's all it does. It's up to you to link the recordset to your view and to your document. By embedding a CEx31aSet object inside the CEx31aDoc class, you ensure that the recordset object will be constructed when the application starts.

The view could always get the recordset from the document, but it's more efficient if the view has its own recordset pointer. Notice how the view's OnInitialUpdate function sets the m_pSet data member.

If you run AppWizard with either of the Database View options, AppWizard generates a class derived from CRecordset, a class derived from CRecordView (for ODBC), and all the necessary linkage as just described. We're not using AppWizard in this mode because we don't want a form-based application.

The CEx31aView Class's OnInitialUpdate Member Function

The job of the CEx31aView::OnInitialUpdate function is to open the recordset that's associated with the view. The recordset constructor was called with a NULL database pointer parameter, so the CRecordset::Open function knows it must construct a CDatabase object and link that database one to one with the recordset. But how does Open know what data source and table to use? It calls two CRecordset virtual functions, GetDefaultConnect and GetDefaultSQL. ClassWizard generates implementations of these functions in your derived recordset class, as shown here:

CString CEx31aSet::GetDefaultConnect() {     return _T("ODBC;DSN=Student Registration"); } CString CEx31aSet::GetDefaultSQL() {     return _T("[Student]"); }

ClassWizard and AppWizard place brackets around all column and table [names]. These brackets are necessary only if the names contain embedded blanks.