PROJECT REPORT

ON
“HUMAN RESOURCE MANAGEMENT”
OF
STATE BANK OF INDIA
KOHIMA BAZAR BRANCH
KOHIMA NAGALAND-797001

Submitted in partial fulfillment of the requirement of major project in the

6th semester for the award of the degree of
B.Sc IT
OF
SIKKIM MANIPAL UNIVERSITY
OF HEALTH, MEDICAL &TECHNOLOGICAL SCIENCES
SESSION - July 2009

Submitted by:
NAME : ADAHRA
Submitted by GRACE
B.Sc IT 6th SEMESTER REGN.
Under the
NO-520753641

Guidance
Miss Daisy Kalitaof

FACULTY, DEPARTMENT OF COMPUTER SCIENCE

SIKKIM MANIPAL UNIVERSITY
Central IT College, of Health, Medical and
Guwahati-6
Technological Sciences Distance Education Wing, Syndicate
House, Manipal-576119.
I hereby decla
RESOURCEMA
 ACKNOWLEDGEMENT
Through this column, I would like to convey my heartfelt

thanks to all those who provided their invaluable guidance

and helpful suggestions during the development of this

project work”.

Firstly, I convey my heartfelt thanks to my project guide

Madam Daisy Kalita, for her tireless efforts & incessant

support during the course of this project work.

I further express my warm gratitude to Sir Deep

Battacharjee, Branch Manager of State Bank Of India

Kohima Bazaar Branch, for his kind permission to carry out

my Project work on “ Human Resource Management ”, and

also for his encouragement & valuable suggestion as in

carrying out my project work.

SIKKIM MANIPAL UNIVERSITY

OF
Health, Medical and Technological Science, syndicate house, Manipal-576104

Project work evaluation

Name : Adahra Grace

Roll No :520753641
Project Title : Human Resource Management
Submitted for Course : BSC-IT 6th semester
Year : 2010
Study center code :01729
Study center name : Central IT College, Ganeshguri, Guwahati-06
Project Guide : Daisy Kalita

ABSTRACT
1. Title of the Project : “ Human Resource

Management”
2. Objective of the Project : This Project is developed to enable
the administrator as well as the user
to have easy access to the database in
the storing of the data and retrieving
of the same.
3. Hardware Specification : Processor – PentiumIV
Ram – 512 MB
HDD – 40 GB and above
 Monitor – 15” VGA (Color)
Keyboard – 101 Keys or
/Mouse Multimedia Standard
4. Software Specification : Operating System – Windows XP
Front End – VB.NET
Back End – SQL Server 2005

CONTENTS
Particulars:
1. Introduction
Introduction

About the Company

2. Objectives
3. Problem Statement
Proposed System
Scope of the proposed system
Advantage of the proposed system

4. Requirement Analysis
Introduction
Requirement Analysis
Measurable goals

5. Analysis & Design

introduction
Context Diagram
Data Flow Diagram
Entity-Relationship diagram
Database structure
Data Dictionary
6. Coding
7. Testing Procedures
8. Documentation
9. Future Application
10. Conclusion
11. Bibliography

Project

Guidelines
Project Category:
This project has been developed for computer network and also can be run in

stand-alone machine.
The development pattern
To develop a system and runs the project needs the platform or operating system. But
for this project needs not any hard and fast rule for a platform. So I build this project
on Windows XP and SQL Server 2000

Minimum requirement for running this project;

Hardware minimum requirements:

Processor : Intel Pentium IV or above

Hard Disk: 40 GB or above
Memory: 512 MB or above
1.44MB Floppy Drive
CD/RW : 52x-32x-52x
Monitor : 15" SVGA Color Monitor Display or above
Mouse : Microsoft Compatible and others
 Multimedia Keyboard or General Keyboards

Software minimum requirements

SQL Server 2005

Tools and Environment used

visual Basic.Net Frame Work for Font-End
SQL Server for Back-End Database

INTRODUCTION
 CHAPTER 1 : INTRODUCTION
INTRODUCTION
There has been a significant achievement in the field of IT which impact has influenced the
human life a lot. Computers have changed the working standards of the people and also their
lives. So in today’s world knowledge of computers is a must.
For any organization to grow high, they should start IT projects for their own working or for
automating the services offered by them. If planned well not only the projects gets executed
but also the desired objective are achieved in time without any time-cost overrun and
monitoring becomes easier.
OBJECTIVES
OBJECTIVE OF THE SOFTWARE
The new system that is being developed would address the drawbacks of the existing manual system. Here, the
proposed system is the computerized information system to provide relief to the organization staff from the
currently inefficient manual system which is very time consuming and provide functions to store or retrieve the
information more efficiently and with greater accuracy. Also, with the use of Database Management System
(DBMS), there is a provision for the storage of large amount of data and would avoid data redundancy.

ADVANTAGES OF PROPOSED SYSTEM

• Save time and effort.

• Reduce paper and manual work.

• Accuracy.

• Enhanced data security.

• Easy access of information when required.

PROBLEM

STATEMENT
 CHAPTER 3 : PROBLEM STATEMENT
3.1 Problem Statement
Systems are created to solve problems. One can think of the systems approach
as an organized way of dealing with a problem. Analysis involved a detailed
study of the current system, leading to specifications of a new system. Analysis
is a detailed study of various operations performed by a system and their
relationships within and outside the system. During analysis, data are collected
on the available files, decision points and transactions handled by the present
system.. Using the following steps it becomes easy to draw the exact boundary
of the new system under consideration:

• Keeping in view the problems and new requirements

• Workout the pros and cons including new areas of the system

Some of the Major problems of manual systems are:

Paper is tearable and needs lots of trees that are becoming to extinct in nature.
•
It can intentionally be hidden by the employees
•
In either case (lost or hidden), when records are not found, their corresponding
•
records should be opened and processed, excess labour costs occur. Eventually

efficiency decreases.

Probability of error is more

•
Large storage is required
•
Tiresome work for the one who maintains it.
•
It takes time to find the records in case of urgent request.
•
It takes time to print the records which brings overtime work and causes some delay
•
in finishing the work

3.2 Proposed System

3.2.1Description
 Proposed System is the result of tedious manual work which provides
users to gain updated information more efficiently and effectively.The main
objectives of the proposed system are-

• Easily manageable
• Provide information at finger tips
• Provide latest information
• Avoid data redundancy

3.2.2 Scope

The most important aspects of the proposed system is to work

efficiently in the application field and reduce excessive time usage and
labour in record maintenance, resulting in faster working environment.

Advantages of the Proposed System

• Probability of error is less

• Records can be maintained easily
• keeping backup of database file is possible
• Easy to handle
• Retrieval of records will be faster
• Interface is user friendly

• Reduce harassed manual work

Limitations of the Proposed System

• It is designed only to input complaints and Calculate pay due

to system downtime
• Future modifications may be required as necessary with
requirements
 REQUIREMEN

ANALYSIS
CHAPTER 4: REQUIREMENT ANALYSIS
1. Introduction
Requirements Analysis is the process of understanding the customer needs and expectations
from a proposed system or application and is a well-defined stage in the Software
Development Life Cycle model.
Requirements are a description of how a system should behave or a description of system
properties or attributes. It can alternatively be a statement of ‘what’ an application is
expected to do.
Requirements analysis is critical to the success of a project. Requirements must be
measurable, testable, related to identified business needs or opportunities, and defined to a
level of detail sufficient for system design.
Why is Requirements Analysis necessary?
Studies reveal that inadequate attention to Software Requirements Analysis at the beginning of a project
is the most common cause for critically vulnerable projects that often do not deliver even on the basic
tasks for which they were designed. There are instances of corporations that have spent huge amounts
on software projects where the end application eventually does not perform the tasks it was intended
for.
Software companies are now investing time and resources into effective and streamlined Software
Requirements Analysis Processes as a prerequisite to successful projects that align with the client’s
business goals and meet the project’s requirement specifications.
 2. Requirements Analysis
This topic is concerned with the process of analyzing requirements to

• Detect and resolve conflicts between requirements

• Discover the bounds of the software and how it must interact with its
environment
• Elaborate system requirements to derive software requirements

The traditional view of requirements analysis has been that it be reduced to conceptual
modeling using one of a number of analysis methods such as the Structured Analysis and
Design Technique (SADT). While conceptual modeling is important, we include the
classification of requirements to help inform trade-offs between requirements (requirements
classification) and the process of establishing these trade-offs (requirements negotiation).
Care must be taken to describe requirements precisely enough to enable the requirements to
be validated, their implementation to be verified, and their costs to be estimated.

Measurable goals

Best practices take the composed list of requirements merely as clues and
repeatedly ask "why?" until the actual business purposes are discovered.
Stakeholders and developers can then devise tests to measure what level of each
goal has been achieved thus far. Such goals change more slowly than the long
list of specific but unmeasured requirements. Once a small set of critical,
measured goals has been established, rapid prototyping and short iterative
development phases may proceed to deliver actual stakeholder value long before
the project is half over.

Strategies For Requirements analysis

4.1 Stakeholder interviews

Stakeholder interviews are a common method used in requirement analysis.

These interviews may reveal requirements not previously envisaged as being
within the scope of the project, and requirements may be contradictory.
However, each stakeholder will have an idea of their expectation or will have
visualized their requirements.
4.2 Prototypes

In the mid-1980s, prototyping was seen as the solution to the requirements

analysis problem. Prototypes are mock-ups of an application. Mock-ups allow
users to visualize an application that hasn't yet been constructed. Prototypes
help users get an idea of what the system will look like, and make it easier for
users to make design decisions without waiting for the system to be built. Major
improvements in communication between users and developers were often seen
with the introduction of prototypes. Early views of applications led to fewer
changes later and hence reduced overall costs considerably. However, over the
next decade, while proving a useful technique, prototyping did not solve the
requirements problem:

Managers, once they see a prototype, may have a hard time understanding that the
•
finished design will not be produced for some time.
Designers often feel compelled to use patched together prototype code in the real system,
•
because they are afraid to 'waste time' starting again.
Prototypes principally help with design decisions and user interface design. However,
•
they cannot tell you what the requirements originally were.
Designers and end users can focus too much on user interface design and too little on
•
producing a system that serves the business process.
Prototypes work well for user interfaces; screen layout and screen flow but are not so
•
useful for batch or asynchronous processes which may involve complex database updates
and/or calculations.

Prototypes can be flat diagrams (referred to as 'wire frames') or working

applications using synthesized functionality. Wire frames are made in a variety
of graphic design documents, and often remove all color from the software
design (i.e. use a greyscale color palette) in instances where the final software is
expected to have graphic design applied to it. This helps to prevent confusion
over the final visual look and feel of the application.

4.3 Use cases

A use case is a technique for documenting the potential requirements of a new

system or software change. Each use case provides one or more scenarios that
convey how the system should interact with the end user or another system to
achieve a specific business goal. Use cases typically avoid technical jargon,
preferring instead the language of the end user or domain expert. Use cases are
often co-authored by requirements engineers and stakeholders.
Summary:

In this module, we’ll discover effective techniques for managing the

requirements engineering process all the way through the development cycle. It
is concerned with the definition of software requirements and the products
generated in that definition. The process involves requirements identification,
requirements analysis, requirements specification, requirements communication
and development of acceptance criteria and procedures.
 SYSTEM
ANALYSIS
&
DESIGN
CHAPTER 5: ANALYSIS AND DESIGN

Introduction:

5.1 System Analysis

Analysis involved a detailed study of the current system, leading to specifications
of a new system. Analysis is a detailed study of various operations performed by
a system and their relationships within and outside the system. During analysis,
data are collected on the available files, decision points and transactions handled
by the present system. Interviews, on-site observation and questionnaire are the
tools used for system analysis. Using the following steps it becomes easy to draw
the exact boundary of the new system under consideration:

• Keeping in view the problems and new requirements

• Workout the pros and cons including new areas of the system

All procedures, requirements must be analysed and documented in the form of

detailed data flow diagrams (DFDs), data dictionary, logical data structures and
miniature specifications. System Analysis also includes sub-dividing of complex
process involving the entire system, identification of data store and manual
processes.

The main points to be discussed in system analysis are:

• Specification of what the new system is to accomplish based on the user

requirements.
• Functional hierarchy showing the functions to be performed by the new
system and their relationship with each other.
• Function network which are similar to function hierarchy but they highlight
the those functions which are common to more than one procedure.
• List of attributes of the entities - these are the data items which need to be
held about each entity (record)

On the basis of result of the initial study, feasibility study takes place. The
feasibility study is basically the test of the proposed system in the light of its
workability, meeting user’s requirements, effective use of resources and .of
course, the cost effectiveness. The main goal of feasibility study is not to solve the
problem but to achieve the scope. In the process of feasibility study, the cost and
benefits are estimated with greater accuracy

5.2 System Design

Based on the user requirements and the detailed analysis of a new system, the
new system must be designed. This is the phase of system designing. It is a most
crucial phase in the development of a system. Normally, the design proceeds in
two stages:

• preliminary or general design

• Structure or detailed design

Preliminary or general design: In the preliminary or general design, the features

of the new system are specified. The costs of implementing these features and the
benefits to be derived are estimated. If the project is still considered to be
feasible, we move to the detailed design stage.

Structure or Detailed design: In the detailed design stage, computer oriented

work begins in earnest. At this stage, the design of the system becomes more
structured. Structure design is a blue print of a computer system solution to a
given problem having the same components and inter-relationship among the
same components as the original problem. Input, output and processing
specifications are drawn up in detail. In the design stage, the programming
language and the platform in which the new system will run are also decided.

There are several tools and techniques used for designing. These tools and
techniques are:

• Context Diagram
• Data flow diagram (DFDs)
• Data dictionary
• Structured Charts
• State Flow Diagram
• Entity Relationship Diagram
 DATABASE STRUCTURE

TABLE NAME: EMPLOYEE

FIELD NAME DATA TYPE SIZE KEY

Emp_id nvarchar 5 Primary

name nvarchar 50

add nvarchar 50

Phone_no nvarchar 10

Emp_Designation nvarchar 30

Emp_DOB nvarchar 20

Emp_DOJ nvarchar 50

TABLE NAME: PROMOTION

FIELD NAME DATATYPE SIZE KEY

Promotion_id nvarchar 50

Emp_id nvarchar 5 Foreign

Promotion level nvarchar 50

D_O_P nvarchar 50

TABLE NAME: LEAVEDETAILS

FIELD NAME DATATYPE SIZE KEY

Leave_id nvarchar 50

Employee_id nvarchar 5 Foreign

Type_of_leave nvarchar 50

Dateofleave nvarchar 50

No_of _leave int 4

TABLE NAME: LOGIN

FIELD NAME DATATYPE SIZE KEY

USER_ID nvarchar 10

PWD nvarchar 10

REPWD nvarchar 10

TYPE nvarchar 30

NAME nvarchar 50
TABLE NAME: SALARY

FIELD NAME DATA TYPE SIZE KEY

EMPLOYEE_ID nvarchar 5

SLIP_ID nvarchar 5

Emp_Name nvarchar 50

BASIC nvarchar 20

TA nvarchar 20

DA nvarchar 20

HRA Nvarchar 20

Others Nvarchar 20

PF Nvarchar 20

GPF Nvarchar 20

Gross_Pay Nvarchar 20

Total_deduction Nvarchar 10

Net_Pay Nvarchar 20

Month Nvarchar 4

year nvarchar 4
 DATA DICTIONARY

SL FIELD NAME DESCRIPTION DATA TYPE SIZE TABLE USED KEY

NO

1 Emp_id Employee identification nvarchar 5 Employee,Promotion, Primary(for

LeaveDetails,Salary Employee),
foreign

2 Name Employee name nvarchar 50 Employee,Salary

3 add Employee address nvarchar 50 Employee

4 Phone_no Employee phone number nvarchar 10 Employee

5 Emp_Designation EmployeeDesignation nvarchar 30 Employee

6 Emp_DOB Employee date of birth nvarchar 20 Employee

7 Emp_DOJ Date of joining nvarchar 50 Employee

8 Promotion_id Promotion identification nvarchar 50 Promotion

9 Promotion level Promotion level nvarchar 50 Promotion

10 D_O_P Date of promotion nvarchar 50 Promotion

11 Leave_id Leave identification nvarchar 10 Leave details

12 Type_of_leave Types of leave nvarchar 20 Leave details

13 DateOfleave Date of leave nvarchar 8 Leave details

14 No_of_leave Number of leave int 4 Leave details

15 User_id Employee identication nvarchar 10 Login

16 Pwd Pay slip no nvarchar 10 Login

17 Repwd Basic pay nvarchar 10 Login

18 Type Gross pay nvarchar 30 Login

19 name Employee name nvarchar 50 Login

SL NO FIELD NAME DESCRIPTION DATA TYPE SIZE TABLE USED KEY

20 SLIP_ID Pay slip identification Nvarchar 5 Salary

21 BASIC Basic pay Nvarchar 20 Salary

22 TA Travelling allowance Nvarchar 20 Salary

23 DA Dearance allowance Nvarchar 20 Salary

24 HRA House rent allowance Nvarchar 20 Salary

25 Others Any other type of allowance Nvarchar 20 Salary

26 PF Profited fund Nvarchar 20 Salary

27 GPF Gross profited fund Nvarchar 20 Salary

28 Gross_pay Gross payment Nvarchar 20 Salary

29 Total_deduction Total deduction of pay Nvarchar 10 Salary

30 Net_Pay Net payment Nvarchar 20 Salary

31 Month Month of pay int 4 Salary

32 year Year of payment int 4 Salary

s
CONTEXT DIAGRAM
A system context diagram (SCD) in software engineering and system engineering are diagrams that represent all external
entities that may interact with a system. This diagram is the highest level view of a system, similar to block diagram, showing
a possibly software-based, system as a whole and its inputs and outputs from/to external factors. It
is the initial stage of system analysis. Expanding the context diagram we can get the detailed DFD of the system. Context
diagram is generally used to show the sources of data and the destination where the processed data goes.
Request Request

Response
Employee HumanResource Administrator
Response Response
Management
DATA FLOW DIAGRAM, 1st LEVELDFD

Provide employee
info Update/
retrieve
1.0Process
EMPLOYEE
employee Emp_records
information
Employee_id
Send emp
details
Applied for
Updates
2.0 leave_information
Process
leave
Verify leave

Send emp details

gets updates pay _details

3.0
Process
salary
Employee details
qualifies for
4.0 updates
Process promotion_details
promotion

Update records
s

Sendsid Emp_records
Get employeeid

EMPLOYEE 3.1

checks
Leave_records

Sendleave

details

Payslip Payrecords
3.2
Updatepay
GetsSalary
details

Fig: 2nd Level DFD for Salary

Qualifiedforpromotion
Sendpermission
Employee 4.1
Emp_records
ChecksEmployee

History

Verifies,yes Updateemployeerecords

PromotionDetails
4.2
Updatedesignation
Updatepromotion
Promotion
details

Fig: 2nd Level DFD for Promotion

 E R DIA GR AM

Emp- doj
Emp _d esig natio n Types of Dateofleave
name add leave
Emp_id Emp_id No of
Emp_ DOB leave

EMPLOYEE takes LEAVE

1 M Lea ve_id

Promotion
Pho ne_ no
level
Emp_id D_o _p

1 1 gets
M
PROMOTION Prom otion _id

Basic
slip_id pay Gross
Emp_id pay 1
gets

SALARY increments

1 1
T otal_ ded uctio nN et_p a y
pf
TA
DA HRA others
g pf

mo nth
year
 SYSTEM TESTING AND

IMPLEMENTATION

PROCEDURE
INTRODUCTION
The process of ensuring that the information system is operational and then allowing users to take over its
operation for use and evaluation is called implementation. The system analyst has several approaches to
implementation that should be considered as the changeover to the new system being prepared. They include
shifting more computer power to users through distributed processing, training, users, converting from the old
system, and evaluating the new one.
The first approach to implementation concerns that the movement of computer power to individual users by
setting up and shifting computer power and responsibility to groups throughout the business with the help of
distributed computing.
The second approach to implementation is using different strategies for training users and personnel, using a
variety of training techniques, and making sure that each user understands any role that he/she must take on
because of the new information system.
The third approach to implementation is choosing a conversion strategy. The system analyst needs to weigh
the situation and purpose a conversion plan that is appropriate for the particular organization and information
system.
The fourth approach to implementation involves evaluating the new or modified information system. The
analyst needs to formulate performance measures to evaluate the system. Evaluations come from users,
management, and analyst themselves.

TESTING PLAN
Testing is the major quality control measure used during software development. Its basic function is to detect
errors in the software or project. During requirement analysis and design, the output is a document that is
usually textual and non-executable. After the coding phase, computer programs are available that can be
executed for testing processes. This implies that testing not only has to uncover errors introduced during
coding, but also errors introduced during the previous phase. Thus the goal of testing is to uncover
requirement, design, and coding errors in the programs. Consequently a different level of testing is used.
Psychology of testing:
The aim of testing is often to demonstrate that a program works by showing that it has no errors. This is the
opposite of what testing should be viewed as the basic purpose of the testing phrases is to detect errors that
may be present in the program. Hence one should not start testing with the intent of showing that a program
works; but the intent should be to show that a program does not work. Thus, testing is the process of executing
a program with the intent of finding the errors.

TYPES OF TESTING:
White Box Testing:
White-box testing is sometimes called glass box testing. It is a test case design method that uses the control
structure of the procedural design to derive test cases.
• Guarantees that all independent paths within a module have been exercise at least once.

• Exercise all logical decisions on their true and false sides.

• Execute all loops at their boundaries and within their operational bounds.

• Exercise internal data structures to assure their validity

Basic path testing:

The basic path method enables the test case designer to derive a logical complexity measure of a
procedural design and use this measure as a guide for defining a basic set of execution paths. Test cases
derived to exercise the basic sets are guaranteed to execute every statement in the program at least once
at the time of testing.
Control Structure Testing:
Control structure testing is one of the techniques for the basic path testing. Although basic path testing is
simple and highly effective, it is not sufficient in itself.
• Condition testing: The condition testing method focuses on testing each condition in the

program.

• Data flow testing: Data flow testing method select paths of a program according to the location of

definition and user of variables in the program.

Black-Box Testing:
Black-Box testing focuses on the functional requirements of the software. That is, black-box testing enables to
derive sets of input conditions that will fully exercise all functional requirements for the program.
Black-box testing attempts to find errors in the following categories:
• Incorrect or missing functions.

• Interface errors.

• Performance errors.

• Initialization and terminal errors.

LEVELS OF TESTING
The faults can occur during any phases in the project or software development cycle. Verification is performed
on the output of each phase, but some faults will be eventually reflected in the code. Testing is usually relied on
to detect these faults introduced during the coding phase itself. Due to these, different levels of testing are used
in the testing process.
The basic levels are unit testing, integration testing, system testing and acceptance testing. These different
levels of testing attempt to detect different types of faults.
Client needs Acceptance
Requirements System Testing
Design Integration Testing
Code Unit Testing
Figure: Levels of testing
The first level of testing is called unit testing. In this, different modules are testing against the specifications
produced during design of the modules.
The second level of testing is often called integration testing, where many unit tested modules are combining
into subsystems, which are tested.
The next levels are system testing and acceptance testing. Here the entire software system is tested. The
reference document for this process is the requirement document and the goal is to see if the software meets
its requirements.

DOCUMENTATION

frmlogin
 Mainform

FrmEmployee
FrmSalary

Frmleave
 FrmPromotion

FrmCeateUser
FrmChangePwd
 RptEmployees

FUTURE

APPLICATION
 FUTURE APPLICATION
I expect that by using the computerized database management, administrator will find it simpler to access
and to upload data as well as retrieving from the database. Through this database, I aim for more forms
and futures to be added.
I do realize that there is nothing like perfect and hence we would welcome constructive comments and
suggestions from the user in order to improve and upgrade this database.

CONCLUSION
CONCLUSION
I have developed this database on Human Resource Management with a view that due to the changing
world everything is made computerized. Nowhere can we find work done without the use of computers.
So with that view, I came up with the plan to develop a database on record maintenance so that the
record in the related fields can be recorded and maintained in a single application.
I have designed this database for convenience, security, and faster access of the employee record by the
user. It is also convenient for those who administers because they can save the data in the database,
which will be more secure in terms of data loss and error in the database. Also it can save more time as
keeping or maintaining in a written file takes more time and is not secure in terms of errors, lost of data
and mismanagement.
The structure query language tools help not only in accessing to the relevant data but also help the
decision-maker to take a better decision. Thus the database does not remain passive on the hard disk of
the computer, it is kept in such an active way that it itself prompts the decision-maker to use it from time
to time depending upon the need of any activity involving use of data for arriving to a decision.
By using this database design, we conclude that it is more efficient, easy, fast and more secure to store
the data and retrieve from the database when the person administers the database.

BIBLIOGRAPHY
BIBLIOGRAPHY
Listed below are some books and websites referred for the development of “Human Resource
Management” software.
1. Black Book in VB.Net2005 :- Dreamtech publication

2. Mastering VB.NET :- Petroutsos

3. VB.NET complete :- BPB Publications

4. Pro SQL Server 2005 :- Thomas Rizzo

5. SQL Server Programming :- Fernando Guerrero

URLs

 http:// www.ondotnet.com/pub

 http:// www.developer.com

 http:// www.ostrosolf.com

 http:// www.vbtuter.net
 http:// www.troobloo.com/tech/vb.net.shtml