Click to open or copy the STDREG project files.
STDREG is a tool for populating the Student Registration database, an open database connectivity (ODBC) data source used by the Enroll database tutorial. It illustrates how to dynamically create tables and columns in a database using direct structured query language (SQL), but works with any database format for which there is an ODBC driver.
Before running the sample, choose a database format and ODBC driver for the Student Registration database. To use Microsoft Foundation Class Library (MFC) database support for SQL Server, you must have the SQL Server product and the ODBC driver for SQL Server.
To use other database formats requires the database management system (DBMS), as well as the ODBC driver. To obtain 32-bit ODBC drivers for other databases, contact Microsoft or other ODBC driver vendors.
To use the Microsoft Access database format, use the Stdreg32.mdb file. For any other database format, you must create a new empty database schema for the Student Registration database using the database administration capability of your DBMS.
After you create the new empty database schema, you must then register the new database with ODBC. You can do this by either using the Control Panel ODBC tool or by running STDREG and choosing the Add Data Source option.
Creating New Tables
Once the database is registered with ODBC, choose the Initialize Data option of STDREG. You will be prompted with three dialog boxes titled Enter SQL Column Syntax. The STDREG tool sends CREATE TABLE SQL statements to create new tables in the Student Registration database. The syntax of the column-element portion of the CREATE TABLE statement is database-dependent. The dialog box implies what database-specific column types the database associates with the three ODBC-defined column types: SMALLINT, INTEGER, and VARCHAR. The STDREG tool determines these by calling SQLGetTypeInfo. Once these column types are determined, choose the appropriate column type based on your knowledge of the particular database.
The STDREG tool is designed to create tables in any arbitrary ODBC database. Therefore, it must determine how three ODBC data types used in the Student Registration application (SQL VARCHAR, SQL INTEGER, and SQL SMALLINT) are named internally by the DBMS. The STDREG tool queries the ODBC driver (using SQLGetTypeInfo) to find out what internal data types correspond to these SQL data types.
The ODBC driver may list more than one internal data type, or the driver may list data type creation parameters, such as "max length" for a VARCHAR. In these cases, it is difficult for STDREG, or any database-independent application, to choose the right internal data type, or to interpret the data type creation parameter. Therefore, STDREG displays the internal data types and asks you to use this information to specify the correct syntax for the internal data type.
Any given DBMS may define internal data types with names other than the standard data type names defined by ODBC. Normally, ODBC and MFC database applications do not need to refer to the data type names used internally by the DBMS; however, the SQL CREATE TABLE statement is an important exception. ODBC does not attempt to interpret the data types specified for the one or more table columns specified in the CREATE TABLE statement. The application sending the CREATE TABLE statement must know the data type names supported by the specific DBMS.
After you have supplied the three column types, STDREG creates six tables in the Student Registration database. Upon completion, choose Exit. You can then run any of the STEP versions of the ENROLL sample using your new database.
Note Although STDREG creates columns in each table of the Student Registration database, STDREG does not create referential integrity rules such as "the COURSE table is a foreign key of the course column of the SECTION (course section) table." Consequently, it is possible to use version STEP4 of the ENROLL sample to add incorrect data or delete a course even though one or more course sections are associated with it.
This sample demonstrates the following keywords:
AfxGetApp; AfxMessageBox; AfxThrowDBException; CCmdTarget::BeginWaitCursor; CCmdTarget::EndWaitCursor; CDC::DrawIcon; CDC::GetSafeHdc; CDC::SetMapMode; CDatabase::Close; CDatabase::ExecuteSQL; CDatabase::Open; CDialog::DoModal; CDialog::EndDialog; CDialog::OnInitDialog; CDialog::OnOK; CFieldExchange::SetFieldType; CListBox::AddString; CListBox::ResetContent; CMenu::AppendMenu; CObject::AssertValid; CObject::Dump; CRecordset::AddNew; CRecordset::Close; CRecordset::DoFieldExchange; CRecordset::GetDefaultConnect; CRecordset::GetDefaultSQL; CRecordset::IsEOF; CRecordset::IsOpen; CRecordset::MoveFirst; CRecordset::MoveNext; CRecordset::OnSetOptions; CRecordset::Open; CRecordset::Update; CString::Empty; CString::Format; CString::GetLength; CString::IsEmpty; CString::LoadString; CWinApp::Enable3dControls; CWinApp::InitInstance; CWinApp::LoadStdProfileSettings; CWnd::CenterWindow; CWnd::DoDataExchange; CWnd::GetClientRect; CWnd::IsIconic; CWnd::OnPaint; CWnd::OnQueryDragIcon; CWnd::OnSysCommand; CWnd::SendMessage; CWnd::SetWindowText; CWnd::UpdateData; GetSystemMenu; GetSystemMetrics; LoadIcon; afxTraceFlags; exit