Microsoft Visual C++ .NET Professional Projects - Premier Press
.pdf
170Project 1 DATABASE PROGRAMMING USING VC++.NET
3.Navigate to any other record in the recordset using any of the navigation
functions: MoveNext, MovePrev, MoveFirst, and MoveLast. This ensures
that the current code is not pointing to a deleted record. These functions automatically call the Update function.
The following code snippet displays the code to delete a record from a data source:
m_pSet->Delete(); |
Y |
|
m_pSet->MoveNext(); |
||
L |
||
if (m_pSet->IsEOF()) |
||
F |
||
{ |
||
|
||
m_pSet->MoveLast(); |
|
|
} |
A |
|
Modifying Records |
||
The following are the steps to modifyMrecords: |
||
1. |
Navigate to the record that needs to be modified. |
2. |
Invoke the EditEfunction. This function enables you to make changes to |
|
the values Tin the current record. |
3. |
Invoke the Update function to save the changes in the database. |
The following code snippet displays the code to modify a record in a data source:
m_pSet->MoveNext();
m_pSet->Edit(); |
// Perform the necessary data exchange and update |
data in the recordset
m_pSet->Update();
CRecordView Class
The data that has been retrieved from a database can be displayed on a form. The user interface of the form can have controls that the user can use to enter, modify, and examine data. The CRecordView class provides a form view that is directly connected to a recordset object. The Dialog Data eXchange(DDX) mechanism exchanges data between the controls of the record view and the fields in the recordset. The DDX mechanism is encapsulated by the CDataExchange class and is implemented by the DoDataExchange function.
In a nutshell, the RFX and DDX mechanisms can be distinguished as follows:
Team-Fly®
DATABASE MANAGEMENT USING ODBC – AN OVERVIEW |
Chapter 7 |
171 |
|
|
|
The RFX mechanism exchanges data between the recordset and the data source.
The DDX mechanism exchanges data between the fields of the recordset and the controls on the form.
The following code snippet displays the DoDataExchange function for the Student table:
void CDatabaseAppView::DoDataExchange(CDataExchange* pDX)
{
CRecordView::DoDataExchange(pDX);
DDX_FieldText(pDX,IDC_STUDENTID, m_pSet->m_StudentID, m_pSet);
DDX_FieldText(pDX,IDC_STUDENTNAME, m_pSet->m_Name,m_pSet);
DDX_FieldText(pDX,IDC_BATCHID, m_pSet->m_BatchID, m_pSet);
}
Summary
This chapter introduced the different database access technologies: ODBC, DAO, and ADO. You also learned about the different ODBC classes that provide the required support for designing a database-based MFC application. The CDatabase class helps you to establish the connection to a data source from your application. The CRecordset class enables you to extract a set of records from a data source and to update the data source whenever required. The CRecordView class enables you to display the records retrieved in a form view. Besides these classes, you also learned about the various methods of these classes that play a vital role in implementing database-related features in an MFC application.
This page intentionally left blank
Chapter 8
Implementing
Data Access
Technologies
Chapter 7 introduced you to the different data access techniques. You also had a glimpse of the various MFC classes that are available for you to provide database connectivity to your application through ODBC. Now, it’s time to try out those concepts. In this chapter, you will create a project, and in the process learn how to implement the theoretical knowledge you have gained. You will cre-
ate an MFC-based application with database connectivity.
This chapter also presents a real-world scenario and guides you through the steps to create a project that addresses the requirements stated in that scenario. To begin with, I will detail the scenario (case study), and then proceed to explain the procedure to create this project in Visual C++ using MFC.
SaveMyMoney Bank – The Case Study
The SaveMyMoney Bank is a private bank that has been providing banking services for a long time. It has branch offices spread across the United States. The SaveMyMoney Bank is well known for its services and has many satisfied customers. Due to good word-of-mouth of these customers, the bank is witnessing a constant increase in its number of customers. During this growth, small problems have started arising. One of the primary concerns for the management is the increased number of customers complaining about transactions being slower. Additionally, as in other arenas, SaveMyMoney Bank has lots of competition.
SaveMyMoney Bank – The Solution
The management of the bank met to discuss the new issues facing the bank. During the course of discussions, the heads of all branch offices shared their views and suggestions to solve the issues. After a brainstorming session, the team collectively concluded that the best possible solution to address the issues would be to automate the entire banking operation, which would cut down on transaction times, thereby gaining back the confidence of customers, as well as help the bank to stay ahead of its competition. However, the management couldn’t risk automating all
IMPLEMENTING DATA ACCESS TECHNOLOGIES |
Chapter 8 |
175 |
|
|
|
the offices without proof that the strategy would pay off, so it decided to automate the New York City branch office first as a trial run.
The requirement as agreed to by the management is to design a banking application that will handle all day-to-day transactions, including deposits, withdrawals, transfers, and so on. The management also wants to pilot the project with the minimal day-to-day functionality before developing the full-fledged application. They decided that, based on the success and the feedback from the New York office, they would further enhance the application and implement it in all other branches as well as the head office.
To create the required banking application, the management hired a team of programmers. As part of the project development team, you will create a banking application to perform all the banking-related transactions. However, before you begin, you need to look at each phase of the life cycle of the project. The following section discusses the different phases of the project life cycle.
Project Life Cycle
The typical development life cycle of a project involves three phases: project initiation, project execution, and project deployment. Following is an overview of what each stage involves:
Project initiation. A project is “initiated” when there is a need to either develop a new system or enhance and upgrade an existing system. In the case of SaveMyMoney Bank, the need is to design a system from scratch. In the project-initiation phase, a comprehensive project plan is prepared. This plan lists the tasks to be performed during the life cycle of a project. In addition, it also identifies the team members and assigns responsibilities to them based on their skills.
Project execution. During this phase, the team develops the required application. This is the most elaborate phase in terms of project cost and time. This phase can be further divided into the following stages:
Requirements analysis
High-level design
Low-level design
Construction
Integration and testing
176Project 1 DATABASE PROGRAMMING USING VC++.NET
User acceptance test
Project deployment
Project deployment. This is the final stage in the life cycle of a project. During this phase, the application is deployed at the client location. In addition, support is provided to the client for a particular period during which any bugs that might occur in the application after deployment are addressed.
Before getting started with designing the project, I will discuss each of the phases within the project-execution phase.
Requirements Analysis
In the requirements-analysis phase, the programmers interviewed the employees of SaveMyMoney Bank. The team figured out the requirements of the bankers who perform the transactions to be automated. Some common questions that they asked were the following:
What is the amount of data that the branch is currently maintaining?
Is there any data that is commonly used by all branches?
How is the data being maintained currently?
What are the types of transactions that they perform in a day?
Are there any reports generated? If yes, what are the types of reports that they generate?
After gathering the responses to these queries, the programmers analyzed the banking transactions to extrapolate the exact requirements of the project. The programmers also analyzed the various entities for which data needs to be maintained and the ways in which data needs to be modified.
From its interviews, discussions, and analyses, the team concluded that the application should:
Use an SQL Server 2000 database as the back end. Each branch will maintain data related to its customers in this database
Have a user interface (front end) that will be easy to use and user friendly
Provide options that will cater to all activities performed, ranging from providing account-related details to performing day-end activities
IMPLEMENTING DATA ACCESS TECHNOLOGIES |
Chapter 8 |
177 |
|
|
|
The following is the list of requirements that will be addressed by the front end:
Include a Login form so that the users can log in to the application
Handle both cash and check transactions
Issue check books to customers
Commit all pending transactions
Activate or deactivate an account
Manage deposits and withdrawals
Transfer amounts within the branch or across branches or banks
The back-end database requires tables for maintaining customer accounts; check books; transactions, including deposits, withdrawals, and transfers; and login details.
As stated earlier, this project will be piloted in the New York City branch. Also, as per the stated requirements, the management is currently planning to deploy this application locally at the branch offices. They don’t want to deploy this as an intranet or an Internet application. Therefore, the programming team decided to create this as a Windows-based application by using MFC. Another important consideration is that the branch works on the Windows 2000 Server operating system.
High-Level Design
In the high-level design phase, the team decides about the functionality of the system. In addition, the various data input and output formats are finalized. The various operating requirements are also identified during this phase. An approval is taken from the client on the functional specifications documentation of the proposed interfaces for the application. The design of the next phase is based on this design.
The development team decided to design this application as an SDI application that will implement database connectivity through ODBC and use the MFC ODBC classes for providing the interaction between the application and the back end.
I will next provide the designs of the various screens in the application.
The very first screen of the application is the Login screen, shown in Figure 8-1. The user needs to enter the assigned username and password and click on the
178 Project 1 DATABASE PROGRAMMING USING VC++.NET
Submit button. If the entered information is valid, then the application will be loaded. Otherwise, an error message appears indicating that the entered username and/or password are invalid. The user is given three attempts to log on. In case all three attempts are not successful, access to the application is denied. The user can cancel the logon attempt by clicking the Cancel button.
FIGURE 8-1 The Login screen
The application’s main screen is shown in Figure 8-2. This screen displays the account details and provides all other options required to perform the decided functionality. By default, the account details in the first record are displayed.
FIGURE 8-2 The application’s main screen
IMPLEMENTING DATA ACCESS TECHNOLOGIES |
Chapter 8 |
179 |
|
|
|
The following are some of the options available in the main screen:
Add. Users need to click on this button to create a new customer account. As per the requirement, the account number is automatically generated.
Modify. Users need to click on this button to modify an existing record. The user is allowed to modify only the permanent address, mailing address, phone number, and e-mail ID. All other fields are disabled.
Update. Users have to click on this button to update the database with the changes, which can either be the addition of new records or modification of existing records. As per the design, when the user clicks on the Add button, he or she can enter the desired values and then click on the Update button to save the changes in the database. The user needs to follow the same steps for modification.
Cancel. Users can click on this button to cancel any current operation.
DeActivate. Users have to click on this button to deactivate an account. As per the current practice, no records are deleted from the database. Instead, they are deactivated and marked as an unoperational account.
ReActivate. Customers can activate their account any time. To accomplish this, the user has to click on the ReActivate button.
Dep/Wdrl. Users have to click on this button to handle transactions involving deposits and withdrawals. When a user clicks on this button, the Deposit/Withdrawal screen, shown in Figure 8-3, appears. This screen allows you to accept all data related to deposits and withdrawals.
FIGURE 8-3 The Deposit/Withdrawal screen