6.Body

Zeker En Vast 1

Department of Computer Science, Christ University.

1. INTRODUCTION

Zeker En Vast is an insurance company application dealing with the incident claims

of their customers. With various related activities including Client registration,

creation of incidents in three levels, different types of covered insurances, different

policies, insurance approval status, and instant mail to replace the existing manual

process and managing data for this system with a complete and automated

Management Information System.

This system provides ready information about new created incidents, ready status of

the incidents, levels of approvals and also effective and efficient communication

capabilities. The different modules provide various interfaces and accessibility to each

incident is made easier.

Zeker En Vast is a tried and tested insurance software program that has made

reporting very simpler for the company and is user friendly. It makes complete

reporting work easy, reduces tremendous manpower and saves on various direct and

indirect costs. Each type of insurance provides different registration of incidents

depending upon the fields involved and evaluates them with the right input from the

user.

Zeker En Vast is software, which can also be used on other insurance companies. It

has a rich collection many useful Reports, insurance types including Vehicle, Fire,

and Flood. And each covering and handling various types of contents and

components. These are handled by three levels Acceptor, Handler and a Chief. There

can be an acknowledgement send to the customer at every level of the process which

will smoothen the complete progress.

Zeker En Vast 2


1.1 PROBLEM DESCRIPTION

The problem with the existing system is that it is not user friendly, because the

retrieval of data is very slow and data is not maintained efficiently. Second problem is

difficulty in report generating, we require more calculations to generate the report so

it is generated at the end of the session .Third is manual control, all calculations to

generate report are done manually so there is greater chance of errors. Fourth is lots of

paperwork, existing system requires lot of paper work, loss of even a single

register/record led to difficult situation because all the papers are needed to generate

the reports. Fifth is time consuming, every work is done manually so we cannot

generate report in the middle of the session or as per the requirement because it is

very time consuming.

1.2 PROPOSED SYSTEM

The proposed system is user friendly because the retrieval and storing of data is fast

and data is maintained efficiently. Moreover the graphical user interface is provided

in the proposed system, which provides user to deal with the system very easily.

Reports are easily generated in the proposed system so user can generate the report as

per the requirement (daily, monthly) or in the end of the session. User can have

regular check on Incidents carried on in Zeker en Vast. It requires very less paper

work, all the data is fitted into the computer immediately and reports can be generated

through computers. Moreover work becomes very easy because there is no need to

keep data on papers. Computer operator control will be there so no chance of errors.

Moreover storing and retrieving of information is easy. Searching for Blood group is

done much easily. The proposed system is entitled Zeker En Vast

using C# as the front end and SQL as the back end. The basic purpose of the system is

to accommodate and maintain the records of all the Incident details. The time required

is very less. The data are distributed efficiently. As the required hardware for the

proposed system is already present with the organization, we need to install only

specific software's which will support the working of the proposed system. The new

system covers all the aspects of the existing system as well as enhanced features for

the existing system.

Zeker En Vast 3


The new system is been developed keeping in mind the current and future

requirements of the organization. The new system will operate feasibly and will

contain an automated database for storage. Reduces space requirements and there is

no duplicacy. Reduces data redundancy and data verification is possible since all the

data is linked to each other.

1.2 PROJECT SCOPE

The proposed system aims at providing data security and reliability for the users.

The advantages of the proposed system are as follows:

Redundancy is avoided.

The system is a stand-alone application.

The modules are well organized.

Provides clear user interfaces, so it is easy to enter and retrieve data.

Reliability is provided to the customers.

The security of the data can be ensured beforehand, there is very less chance of the

data being lost.

Auto letter generation.

Accuracy in calculation.

It is possible to link the system to an already existing database.

Changes in one system will affect all system since it is a web application and hence

updating data is easy.

1.3 ADVANTAGES OF THE PROPOSED SYSTEM

Saves a lot of time and effort.

Requirement of man power is cut short.

Special measures are taken to keep the data totally secure.

User friendly.

The entire work is executed from a single system.

Software shall be designed to be compatible with all the existing systems

Zeker En Vast 4


1.4 DISADVANTAGES OF THE EXISTING SY STEM

Processes are slow and unreliable.

The monitoring of the work is difficult to maintain in a manual system.

Unnecessary man power is required.

Record maintenance is difficult.

Zeker En Vast 5


2. SYSTEM ANALYSIS

2.1 FUNCTIONAL SPECIFICATION

Zeker En Vast(login Page)

Registering Client

Creating Incident

Selecting type of Insurance.

Approving Incident lesser than 150

Approving Incident greater than 150 and lesser than 11499

Approving Incidents greater than 11499

2.1.1 FUNCTIONS PERFORMED

MODULE

Acceptor

An acceptor can handle the data in an efficient way by entering input and obtaining

output data from the system. He also checks if a claim is within the customers

insurance for the damage level to be noted and a conclusion is made about the

payment of the claim. He also verifies the application to be sent as a letter to the

respective customer so the customer knows if his damage report is being handled or

not and chooses from three different damage levels namely low, middle and heavy.

An automatic message is expected to be sent by the application to the specialist or

handler so that the efficiency will be improved. An acceptor can create incidents

based on automobile, fire and flood insurance.

Handler

The application generates and sends the claimed damage specifications to handler so

that the handler knows what to investigate. Then an automatically generated letter

containing the claim results is sent by handler to the manager. Then the payments are

handled. He also views the damage specifications and decides on what needs to be

investigated.

Zeker En Vast 6


Chief

The Chief approves the investigated final results so that the details clear when the

investigation can be closed. In case of an error the results are sent back to the handler

to make the necessary corrections. If not the approvals are made and transactions are

carried on. The fire and flood insurances are directly viewed and

approved/disapproved by the chief.

Fire

This is a module created for dealing with the fire accidents caused by man. If the

client is registered with the insurance company and he has a valid coverage for the

fire insurance, he is entitled to be registered by acceptor by his request. This fire

insurance is covering only for buildings. There are two types of fire insurance

1) Owned building 2) Rented building. Both of these have their own characteristics

covered and their status is also updated.

Flood

This is a module created for dealing with a natural calamity flood. If the client is

registered with the insurance company and he has a valid coverage for the flood

insurance, he is entitled to be registered by acceptor by his request. This flood

insurance is covered for Land and Crop. Both of these have their own characteristics

covered and their status is updated with regard to the policy.

2.1.2 NON-FUNCTIONAL REQUIREMENTS

The system must be developed to suit the particular needs of a user-friendly

environment. This means that the system must accommodate a clearly

understandable user interface as well as clear online help documentation at any

stage of the user interaction with the system.

A fast response time in obtaining and providing information to the system may

also prove to be a significant advantage. In addition to these requirements, the

system should also embrace the following requirements:-

Zeker En Vast 7


Security: Each user is required to log in. The system should log staff that has

been assigned user names and passwords. The system should be designed to make

it impossible for anybody to logon without a valid username and password. Data

encryption should be employed to keep the user login name and password secret.

Reliability: The system would be used by about maximum of 5 staff working at

the company and also some other many staff in the collaborating at the company.

The system should have little or no downtime and be able to handle multiple

concurrent users.

Ease of Use: The general and administrative views should be easy to use and

intuitive. Online help and documentation should be provided.

Performance: The system should have a quick response time. For the purpose of

this Research project, this would be defined as less than 5 seconds.

System and Browser compatibility Testing: The system should be accessible on

the Following browsers - Microsoft Internet Explorer 5.5+, Netscape Navigator

6.0+ and Mozilla 1. 3.

Easy Operability:

Consistent user interface with every economic design .All computer operations are

button click and when mouse pointer reaches a control tool tip tests are

maintained for user understandability. Simple, easy to understand error messages

are provided.

Maintainability:

The system design is modular which gives scope for easier maintenance and high

reliability. Many types of controls and validations ensure maximum security and

a minimum error rate.

Flexibility:

Since the design is modular, it gives a great flexibility for a system enhancement

and expansion. Integration of new modules is also very easy.

Zeker En Vast 8


2.2 BLOCK DIAGRAM

Fig 2.1 Block diagram

Zeker En Vast 9


2.2 SYSTEM REQUIREMENT

2.3.1 LITERATURE SURVEY

Literature Survey is the most important in software development process. Before

developing the tool it is necessary to determine the time factor, economy and

company strength. Once these things are satisfied, then next step is to determine

which operating system and language can be used for developing the tool. Once the

programmers start building the tool the programmers need lot of external support.

This support can be obtained from senior programmers, from books or from websites.

Before building the system the above consideration are taken into account for

developing the proposed system. Literature review was done by referring books,

journals and internet and through interviews.

The popular C# programming language combines the high productivity of rapid

application development languages with the raw power of C and C++. Updated to

cover the new features of C# 4.0, including dynamic binding, named and optional

parameters, and covariant and contra variant generic types, this release takes the

language to the next level by adding the ability to cleanly write programs that don't

rely on static type definitions. This allows dynamic programming languages such as

Python, Ruby, and JavaScript to feel native to C#. The C# Programming Language,

Fourth Edition, continues to be the authoritative and annotated technical reference.

2.3.2 TOOL SURVEY

Front end : C# .net

Back end : SQL

C#.NET:

C# language is intended to be a simple, modern, general-purpose, object-oriented

programming language. The language, and implementations thereof, should provide

support for software engineering principles such as strong type checking, array

bounds checking, detection of attempts to use uninitialized variables, and automatic

garbage collection. Software robustness, durability, and programmer productivity are

important. The language is intended for use in developing software components

Zeker En Vast 10


suitable for deployment in distributed environments. Source code portability is very

important, as is programmer portability, especially for those programmers already

familiar with C and C++.

C# is intended to be suitable for writing applications for both hosted and embedded

systems, ranging from the very large that use sophisticated operating systems, down

to the very small having dedicated functions. Although C# applications are intended

to be economical with regard to memory and processing power requirements, the

language was not intended to compete directly on performance and size with C or

assembly language.

FEATURES:

It has no global variables or functions. All methods and members must be declared

within classes. Static members of public classes can substitute for global variables

and functions. Local variables cannot shadow variables of the enclosing block.

Managed memory cannot be explicitly freed; instead, it is automatically garbage

collected. Garbage collection addresses the problem of memory leaks by freeing

the programmer of responsibility for releasing memory that is no longer needed.

XML support for Web-based component interaction.

SQL:

SQL is a programming language designed for managing data in relational database

management systems (RDBMS). Two essential purposes of a database language: - to

create and edit the database and to perform queries. The simple fact is that these tasks

are accomplished by users of SQL and SQL powered applications with generally

greater ease and efficiency. SQL has remained the standard-bearing database

language, working behind the scenes on GUI database interfaces and used by those

who need custom-written queries and data-manipulations.

Zeker En Vast 11


The SQL language is subdivided into several language elements, including:

Clauses, which are constituent components of statements and queries.

Expressions, which can produce either scalar values or tables consisting of

columns and rows of data.

Predicates, which specify conditions that can be evaluated to SQL three-valued

logic (3VL) or Boolean (true/false/unknown) truth values and which are used to

limit the effects of statements and queries, or to change program flow.

Queries, which retrieve the data based on specific criteria. This is the most

important element of SQL.

Statements, which may have a persistent effect on schemata and data, or which

may control transactions, program flow, connections, sessions, or diagnostics.

Insignificant whitespace is generally ignored in SQL statements and queries,

making it easier to format SQL code for readability.

SQL Operators:

Operator Description

= Equal

> Greater than

< Less than

>= Greater than or equal

Zeker En Vast 12


2.3.3 Hardware Requirements

2.3.2 Software Requirements

Processor

RAM

Hard disk space

Monitor

Mouse

:

:

:

:

:

:

Intel core 2 or Higher Versions

1GB or More

5GB or More

CRT/LCD Monitor or Any

Compatible Mouse

Front end

Back end

Operating system

:

:

:

C#

SQL Server

Windows XP and Higher Versions

Zeker En Vast 13


3. SYSTEM DESIGN

3.1 SYSTEM ARCHITECTURE

This project Zeker En Vast has three-tier architecture.

Three-tier is a client server architecture in which the user interface, functional

process logic("business rules"), computer data storage and data access are developed

and maintained as independent modules, most often on separate platforms. The

three-tier model is software architecture and a software design pattern.

Apart from the usual advantages of modular software with well-defined interfaces, the

three-tier architecture is intended to allow any of the three tiers to be upgraded or

replaced independently in response to changes in requirements or technology. For

example, a change of operating system in the presentation tier would only affect the

user interface code.

Typically, the user interface runs on a desktop PC or workstation and uses a

standard graphical user interface, functional process logic that may consist of one or

more separate modules running on a workstation or application server, and

an RDBMS on a database server or mainframe that contains the computer data storage

logic. Three-tier architecture has the following three tiers:

Presentation tier: This is the topmost level of the application. The presentation tier

displays information related to such services as client details, policy details, coverage

details, evidences etc. It communicates with other tiers by outputting results to the

browser/client tier and all other tiers in the network.

Application tier (business logic, logic tier, data access tier, or middle tier): The logical

tier is pulled out from the presentation tier and, as its own layer, it controls an

Data tier: This tier consists of database servers. Here information is stored and

retrieved. This tier keeps data neutral and independent from application servers or

business logic. Giving data its own tier also improves scalability and performance.
http://en.wikipedia.org/wiki/Client%E2%80%93server_architecturehttp://en.wikipedia.org/wiki/User_interfacehttp://en.wikipedia.org/wiki/Business_logic_layerhttp://en.wikipedia.org/wiki/Business_logic_layerhttp://en.wikipedia.org/wiki/Computer_data_storagehttp://en.wikipedia.org/wiki/Data_accesshttp://en.wikipedia.org/wiki/Module_(computing)http://en.wikipedia.org/wiki/Platform_(computing)http://en.wikipedia.org/wiki/Software_architecturehttp://en.wikipedia.org/wiki/Software_design_patternhttp://en.wikipedia.org/wiki/Softwarehttp://en.wikipedia.org/wiki/Technologyhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Personal_computerhttp://en.wikipedia.org/wiki/Workstation_(computer_hardware)http://en.wikipedia.org/wiki/Graphical_user_interfacehttp://en.wikipedia.org/wiki/Application_serverhttp://en.wikipedia.org/wiki/RDBMShttp://en.wikipedia.org/wiki/Database_serverhttp://en.wikipedia.org/wiki/Mainframe_computerhttp://en.wikipedia.org/wiki/Business_logic

Zeker En Vast 14


3.2 MODULE DESIGN

When designing a system synthetically, the system could be designed by two broad

ways. The first way would be to design the complete system using the known

theories, and use the system, as it is designed, in the real conditions. An alternative

way would be to design the different components of the system separately, and test

each component in separate conditions. Modular design, or "modularity in design", is

an approach that subdivides a system into smaller parts (modules) that can be

independently created and then used in different systems to drive multiple

functionalities.

ACCEPTOR AND HANDLE R DESIGN

Fig 3.1 Module design

Zeker En Vast 15


CHIEF WORKING DESIGN

Fig 3.2 Module design of chief

3.3. DATABASE DESIGN

3.3.1 TABLE STRUCTURE

3.1 Cost specification table

ATTRIBUTE NAME DATATYPE DESCRIPTIONS

C_id Varchar(50) Unique client id

Est Bigint An estimate of the costs

Idt_dcpn Varchar(50) Incident description

Date Varchar(50) The date of the estimation

Sts Status Status of the incident

Zeker En Vast 16


3.2 Client table


Name Varchar(50) First and last name of the client

Addrs Varchar(50) Address of the client

C_id Varchar(50) Unique client id

P_no Varchar(50) Policy number

Mem_snc Varchar(50) The date on which the client has

become the member

Birth_pl Varchar(50) Birth place of the client

Prfsn Varchar(50) Profession of the client

Phone Bigint Phone number of the client

Cov_des Varchar(50) It is the coverage cdescription

3.3 Incident table


Indt_no Varchar(50) The incident number

C_id Varchar(50) A unique client id

S_date Varchar(50) The date on which the incident has

been registered

Cov_no Bigint Coverage description

Zeker En Vast 17


3.4 Build table


Lctn Varchar(50) Location of the building

Area Varchar(50) Total space used for construction

Cncst Varchar(50) Construction cost

Tvc Varchar(50) Total value of contents

Yrs Varchar(50) Terroriosm cover

Regdate Varchar(50) Registration date of incident

Ownsp Varchar(50) Ownership

C_id Varchar(50) Client id

3.5 Report table


Report Bigint Number of the report

Client Bigint A unique client id

Report description Varchar(50) Description of the report

3.6 Affected coverage table


cov_no Bigint Coverage number

indt_no Bigint Incident number

asgn_amt Varchar(50) Assigned amount

Sts Varchar(50) Status

Zeker En Vast 18


3.3.2 DATA FLOW DIAGRAM

DATA FLOW DIAGRAM

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through

an information system. DFDs can also be used for the visualization of data

processing (structured design). On a DFD, data items flow from an external data

source or an internal data store to an internal data store or an external data sink, via an

internal process.

A DFD provides no information about the timing of processes, or about whether

processes will operate in sequence or in parallel. It is therefore quite different from

a flowchart, which shows the flow of control through an algorithm, allowing a reader

to determine what operations will be performed, in what order, and under what

circumstances, but not what kinds of data will be input to and output from the system,

nor where the data will come from and go to, nor where the data will be stored. This

level (level 1) shows all processes at the first level of numbering, data stores, external

entities and the data flows between them.

The purpose of this level is to show the major and high-level processes of the system

and their interrelation. A process model will have one, and only one, level-1 diagram.

A level-1 diagram must be balanced with its parent context level diagram, i.e. there

must be the same external entities and the same data flows, these can be broken down

to more detail in the level one.

Zeker En Vast 19


DATA FLOW CONTAINS :

Rectangle: data storage.

Bubble: it represents the process.

Arrow: it represents the how the data flowed b\w process and data storage.

A few simple guidelines can aid immeasurably during derivation of a data flow

diagram:

The level 0 data flow diagram should depict the software/system as a single

bubble.

Primary input & output should be carefully noted.

Refinement should begin by isolating candidate processes, data objects, and data

stores to be represented at the next level.

All arrows and bubbles should be labeled with meaningful names.

Information flow continuity must be maintained from level to level.

One bubble at a time should be refined.

DFD Level 0:

Fig 3.3 Data flow diagram level 0

Zeker En Vast 20


DFD Level 1:


DFD Level 2:


Zeker En Vast 21


3.5 INTERFACE DESIGN

3.5.1 USER INTERFACE SCREEN DESIGN

Input facilities the entry of data into the computer system. Input design involves the

selection of the best strategy for getting data into the computer system at the right

time and as accurately as possible. This is because the most difficult aspect of input

designs in accuracy. The use of well-defined documents can encourage users to record

data accurately without omission. For example, the input data such as contact will

take only integers as the input an similar strategy is followed with various other

forms.

Input design must capture all the data that the system needs, without introducing any

errors. Input errors can be greatly reduced when inputting directly by using

appropriate forms for data capture and well-designed computer screen layout.

LOGIN FORM

Fig 3.6: Login form for Acceptor, Handler and Chief

Zeker En Vast 22


ACCEPTOR MAIN FORM

Fig 3.7: Acceptor Main Screen.

CLIENT REGISTRATION

Fig 3.8: Registration for client

Zeker En Vast 23


ACCEPTOR CREATING AN INCIDENT

Fig 3.9: Acceptor creating an incident

ACCEPTOR CLOSING AN INCIDENT

Fig 3.10 Approving Incident lesser than 150

Zeker En Vast 24


APPROVING INCIDNET BY HANDLER

Fig 3.11 Approving Incident greater than 150 and lesser than 11499

CHIEF APPROVING INCIDENTS

Fig 3.12 Approving Incidents greater than 11499

Zeker En Vast 25


Fig 3.13 Sequence diagram for accepting an incident

Fig 3.14 Sequence diagram for handling a small incident

Zeker En Vast 26


Fig 3.15 Sequence diagram for handling a medium incident

Fig 3.16 Sequence diagram accepting a big incident by chief

Zeker En Vast 27


3.6 REPORT DESIGN

These are the formats of the letters used in the application when a communication has

to be made by the users to their respective clients. These are auto generated and will

have all the important details of the client to be sent.

LETTER FORMAT 1

Fig 3.17 Incident Accepted Letter

Zeker En Vast 28


LETTER FORMAT 2

Fig 3.18 Cost Specification Letter

Zeker En Vast 29


LETTER FROMAT 3

Fig 3.19 Exception Letter

Zeker En Vast 30


LETTER FORMAT 4

Fig 3.20 Final Letter

Zeker En Vast 31


LETTER FORMAT 5

Fig 3.21: Not accepted Letter

Zeker En Vast 32


4. IMPLEMENTATION S

4.1. CODING STANDARD:

LOGIN

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using System.Data.SqlClient;

namespace WindowsFormsApplication1

{

public partial class Form6 : Form

{

System.Data.SqlClient.SqlConnection con;

DataSet ds1;

public Form6()

{

InitializeComponent();

}

private void Form6_Load(object sender, EventArgs e)

{

textBox1.Focus();

}

private void button1_Click(object sender, EventArgs e)

{

if (textBox1.Text== "Acceptor")

{

if (textBox2.Text == "acc")

{

Zeker En Vast 33


MessageBox.Show("Logged in as

Acceptor","Information",MessageBoxButtons.OK,MessageBoxIcon.Information);

this.Hide();

Form11 f11 = new Form11();

f11.Show();

}

else if ((textBox1.Text == "Acceptor") || (textBox2.Text != "acc"))

{

MessageBox.Show("Please enter right PASSWORD", "Alert",

MessageBoxButtons.OK, MessageBoxIcon.Warning);

textBox2.Clear();

textBox2.Focus();

}

else

{

MessageBox.Show("Incorrect username/password", "Alert",


textBox2.Clear();

textBox1.Clear();

textBox1.Focus();

}

}

else if (textBox1.Text =="Handler")

{

if (textBox2.Text == "han")

MessageBox.Show("Logged in as Handler", "Information", MessageBoxButtons.OK,

MessageBoxIcon.Information);

this.Hide();


f5.Show();

}

else if ((textBox1.Text == "Handler") || (textBox2.Text != "han"))

{

Zeker En Vast 34




textBox2.Clear();

textBox2.Focus();

}

else

{



textBox2.Clear();

textBox1.Clear();

textBox1.Focus();

}

}

else if (textBox1.Text == "Chief")

{

if (textBox2.Text == "chi")

{

MessageBox.Show("Logged in as Chief", "Information", MessageBoxButtons.OK,

MessageBoxIcon.Information);

this.Hide();


f10.Show();

}

else if ((textBox1.Text == "Chief") || (textBox2.Text != "chi"))

{



textBox2.Clear();

textBox2.Focus();

}

else

{

Zeker En Vast 35




textBox2.Clear();

textBox1.Clear();

textBox1.Focus();

}

}

else

{



textBox1.Clear();

textBox2.Clear();

textBox1.Focus();

}

}

private void textBox1_Leave(object sender, EventArgs e)

{

textBox2.Focus();

}


{

button1.Focus();

}

private void button1_Leave(object sender, EventArgs e)

{

textBox1.Focus();

}

}

}

Zeker En Vast 36


ACCEPTOR MAIN SCREEN:


{


{

public Form11()

{

InitializeComponent();

}


{

panel1.Show();

radioButton1.Enabled = true;

radioButton2.Enabled = true;

radioButton1.Checked = false;


}


{

panel2.Hide();

panel1.Hide();

button3.Focus();

}


{

button2.Focus();

}


{

button3.Focus();

}


{

panel1.Hide();

Zeker En Vast 37


panel2.Hide();


f13.Show();

this.Hide();

}


{

panel1.Hide();

panel2.Hide();


f55.Show();

this.Hide();

}


{

button1.Focus();

}


{


f6.Show();

this.Hide();

}


{


f1.Show();

if ((f1.radioButton1.Checked == true) || (f1.radioButton2.Checked == true))

{

f1.radioButton1.Checked = false || (f1.radioButton2.Checked = false);

}

this.Hide();

}


Zeker En Vast 38


{

panel1.Hide()

}


{

panel2.Show();

panel1.Hide();

}

private void radioButton1_Click(object sender, EventArgs e)

{


this.Hide();

f15.Show();

}

private void radioButton2_Click(object sender, EventArgs e)

{


this.Hide();

f16.Show();

}


{

radioButton1.Enabled = false;

radioButton2.Enabled = false;



panel2.Hide();

button1.Focus();

}

}

}

Zeker En Vast 39


REGISTERING CLIENT:


{


{

System.Data.SqlClient.SqlConnection con;

DataSet ds1;

System.Data.SqlClient.SqlDataAdapter da;

public Form2()

{

InitializeComponent()


{

textBox1.Focus();

}


{

if ((textBox1.Text == "") || (textBox2.Text == "") || (textBox3.Text == "") ||

(textBox4.Text == "") || (textBox5.Text == "") || (textBox6.Text == "") ||

(textBox7.Text == "") || (textBox8.Text == "") || (textBox9.Text == "") ||

(textBox10.Text == ""))

{

MessageBox.Show("The error(s) must be corrected and empty spaces must be filled

before submitting this form", "Error!!", MessageBoxButtons.OK,

MessageBoxIcon.Error);

}

Else

{

MessageBox.Show("Do you wish to submit the information?", "Alert",

MessageBoxButtons.YesNo, MessageBoxIcon.Question);

con = new System.Data.SqlClient.SqlConnection();

ds1 = new DataSet();

Zeker En Vast 40


con.ConnectionString = "Data

Source=.\\SQLEXPRESS;AttachDbFilename=C:\\Users\\Administrator\\Documents\\

Zeker.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True";

SqlCommand comm = new SqlCommand("Insert into Client

(name,addrs,c_id,p_no,mem_snc,birth_pl,prfsn,phone,cov_des) values ('" +

textBox1.Text + "','" + textBox4.Text + "','" + textBox2.Text + "','" + textBox3.Text +

"','" + dateTimePicker1.Value + "','" + textBox5.Text + "','" + textBox6.Text + "','" +

textBox7.Text + "','" + textBox8.Text + "')", con);

SqlDataReader dr1 = comm.ExecuteReader();

con.Close();

con.Open();

SqlCommand comm1 = new SqlCommand("Insert into Incident

(indt_no,c_id,s_date,cov_no) values ('" + textBox9.Text + "','" + textBox2.Text + "','"

+ dateTimePicker1.Value + "','" + textBox10.Text + "')", con);

SqlDataReader dr2 = comm1.ExecuteReader();

con.Close();


f11.Show();

this.Hide();

}

}


{

textBox9.Focus();

}


{

textBox4.Focus();

}


{

button1.Focus();

}

private void textBox1_KeyDown(object sender, KeyEventArgs e)

Zeker En Vast 41


{

if (e.KeyValue >= 48 && e.KeyValue

Zeker En Vast 42


textBox6.Clear();

textBox7.Clear();

textBox8.Clear();

textBox9.Clear();

textBox10.Clear();

}

private void textBox7_KeyDown(object sender, KeyEventArgs e)

{

if ((e.KeyValue > 64 || e.KeyValue > 91) && (e.KeyValue > 96 || e.KeyValue < 123))

{

MessageBox.Show("Please Enter numbers Only", "Error", MessageBoxButtons.OK,

MessageBoxIcon.Error);

int c = textBox7.SelectionStart - 1;

textBox7.Text = textBox7.Text.Remove(c, 1);

textBox7.SelectionStart = c;

}

}


{

textBox7.Focus();

}


{

textBox8.Focus();

}


{

button2.Focus();

}


{

button3.Focus()

}

Zeker En Vast 43


4.2 SCREEN SHOTS

LOGIN SCREEN

Fig4.1 Login form

HANDLER LOGGED IN SCREEN

Fig 4.2 login form for handler

Zeker En Vast 44


CHIEF LOGGED IN SCREEN

Fig 4.3 login form for chief

ACCEPTOR MAIN SCREEN

Fig 4.4 Acceptor main screen

Zeker En Vast 45


ACCEPTOR REGISTERING CLIENT

Fig 4.5 Registering a client

ACCEPTOR INCIDENT CREATION

Fig 4.6 Creation of an incident

Zeker En Vast 46


ACCEPTOR ACCEPTED INCIDENT

Fig 4.7 Incident accepted form

ACCEPTOR OPEN INCIDENTS

Fig 4.8 Acceptor open incidents

Zeker En Vast 47


ACCEPTOR INCIDENT APPROVAL

Fig 4.9 Approval of incidents by acceptor

HANDLER OPEN INCIDENTS

Fig 4.10 Handler open incidents form

Zeker En Vast 48


HANDLER ACCEPTING INCIDENT

Fig 4.11 Handler accepting incident form

CHIEF MAIN SCREEN

Fig 4.12 Chief main screen form

6.Body

Documents

Transcript of 6.Body