Project Structure

Introduction
Migration from one module to another
Analysis of system
Module Description
Elaboration of modules
Features of Migrator
Objective
Tools and Techniques
JAVA
JAVA Swing
JDBC
Oracle Database
Microsoft Access
SQL Server
Software requirements and specifications
Software testing
System Requirements
Model used
Description of modules
Gantt Chart and PERT Chart
Screens
Advantages and Limitations
Conclusion
Bibliography

INTRODUCTION:
This project is all about migration of data from one database package to another database
package. The various database packages that have been used in this project are: MS Access,
Oracle and SQL Server.

The main aim of developing this project is to access the data from one package to another
package. This provides a better means of retrieving the data as needed and in the desired
form, in other words data can be retrieved as per the users’ need.

This project provides the facility of simply transferring data of one package to another
database package. But some limitations of this package are: the system on which it is
installed should have Oracle, MS Access and SQL Server installed on it otherwise it is
useless. Retrieval of data as per the users’ need is the biggest advantage of this project.

There is no need of creating anything manually on each of the mentioned database

packages it performs all task by clicking the buttons only. This is the only manual work it
needs.

ABOUT PROJECT STRUCTURE

This layout is showing the Multiple Document Interface of this project.

MIGRATION FROM ONE DATABASE TO ANOTHER

ANALYSIS OF SYSTEM

The main purpose behind creation of the project is to provide a simple means for data
transfer and database management.This system is based on the Analysis of the
phenomenon of how to transfer the data from one database to another.Analyzing the need
of such a system which can transfer the data easily and successfully this system is created.
MODULE DESCRIPTION –
This project contains six modules:-

1. Migration from Ms-Access to oracle

2. Migration from Oracle to MS-Access

3. Migration from SQL Server to MS-Access

4. Migration from SQL Server to Oracle

5. Migration from Oracle to SQL Server

6. Migration from MS-Access to SQL Server

Module 1: This Module is designed or developed to provide the facility of transferring the
data from MS-Access to Oracle.

Module 2: This Module is designed to transfer the data of Oracle Database to MS-Access
Database. Here we first create the Database in Access then table is created.

Module 3: This Module is designed to migrate the data from SQL Server to MS-Access
Database.

Module 4: This Module is designed to migrate the data from SQL Server to Oracle Database.

Module 5: This Module is designed to migrate the data from Oracle Database to SQL Server.

Module 6: This Module is designed to migrate the data from MS-Access to SQL Server.

ELABORATION OF MODULES:

HOME PAGE
On running this project splash screen will appear first then a login will appear asking for the
password. After the password being accepted by the login the registration form will appear.
Through this form user becomes a registered user.

REGISTRATION
If the new user wants to access the project he has to click on the sign up option on the home
page. After that the registration form appears which contains Userid, Name, Fname, DOB,
Gender, Address, Occupation, City, State, Country, Phno., email, Mobile, Security ques,
Answer, Password, Photograph request from the user.

MDI
It is a Multiple Document Interface (MDI) through which we can access any database. This
introductory form has five options namely Home, MS-Access, SQL Server, Oracle and About
us. After selecting the database name we are directed to the next page where we select the
database name. After selecting the database we are required to fill in the desired table name
whose details are displayed in the next form.
.
.

Module1: Migration from Access to Oracle

This form is performing the operation of transferring the data from MS-Access to Oracle
database.

STEP 1: After selecting the MS-Access option and common dialog box will be displayed
asking for the ‘table name’. All the tables of Access are displayed in a list box from which we
can select the desired table name and then ‘submit the query’. Now just selecting the
desired table will display the contained fields, type of the fields and size of the fields.

STEP 2: After submitting the query, now as we are migrating the data from MS-Access to
Oracle a same table will be created in the oracle database. The form will show the table
created in the oracle database and will show all the field names, data types and the size.
After this clicking the command ‘Show records’ will display the records as they will form a
table in the oracle database.

STEP 3: Now we will see the form where record details are displayed. Then clicking on the
command ‘Move records’ will migrate the data from Access to Oracle.

STEP 4: After the migration the form is displayed which confirms the successful migration of
data from one database to another else it displays if the migration is not successful.

Similarly the processing of all the modules is carried about by using different methods
according to the database.

FEATURES OF MIGRATOR
All the attributes of all data types in Oracle are accepted.
Converts individual tables
Merges Oracle data into an existing MS Access database and vice versa.
Easy-to-use
OBJECTIVES:
The main objectives of this project are:
1.To create such a program that will easily transfer and create the database tables along
with their data.

2. To provide the facility to view the data as per the user’s need.

3. One can easily transfer the data tables form one database to another database and use
them as per their needs.

4. To provide easy access to the different databases.

TOOLS and TECHNIQUES

JAVA:

Java is a programming language originally developed by James Gosling at Sun

Microsystems and released in 1995 as a core component of Sun Microsystems' Java platform.
The language derives much of its syntax from C and C++ but has a simpler object model
and fewer low-level facilities. Java applications are typically compiled to bytecode that can
run on any Java virtual machine (JVM) regardless of computer architecture.

The original and reference implementation Java compilers, virtual machines, and class
libraries were developed by Sun from 1995. As of May 2007, in compliance with the
specifications of the Java Community Process, Sun made available most of their Java
technologies as free software under the GNU General Public License. Others have also
developed alternative implementations of these Sun technologies, such as the GNU Compiler
for Java and GNU Classpath.

James Gosling initiated the Java language project in June 1991 for use in one of his many set-
top box projects.[5] The language, initially called Oak after an oak tree that stood outside
Gosling's office, also went by the name Green and ended up later renamed as Java, from a
list of random words. [6] Gosling aimed to implement a virtual machine and a language that
had a familiar C/C++ style of notation.

Sun released the first public implementation as Java 1.0 in 1995. It promised "Write Once,
Run Anywhere" (WORA), providing no-cost run-times on popular platforms. Fairly secure and
featuring configurable security, it allowed network- and file-access restrictions. Major web
browsers soon incorporated the ability to run Java applets within web pages, and Java
quickly became popular. With the advent of Java 2 (released initially as J2SE 1.2 in December
1998), new versions had multiple configurations built for different types of platforms. For
example, J2EE targeted enterprise applications and the greatly stripped-down version J2ME
for mobile applications. J2SE designated the Standard Edition. In 2006, for marketing
purposes, Sun renamed new J2 versions as Java EE, Java ME, and Java SE, respectively.

In 1997, Sun Microsystems approached the ISO/IEC JTC1 standards body and later the Ecma
International to formalize Java, but it soon withdrew from the process. [8] Java remains a de
facto standard, controlled through the Java Community Process.[9] At one time, Sun made
most of its Java implementations available without charge, despite their proprietary software
status. Sun generated revenue from Java through the selling of licenses for specialized
products such as the Java Enterprise System. Sun distinguishes between its Software
Development Kit (SDK) and Runtime Environment (JRE) (a subset of the SDK); the primary
distinction involves the JRE's lack of the compiler, utility programs, and header files.

On 13 November 2006, Sun released much of Java as free and open source software under
the terms of the GNU General Public License (GPL). On 8 May 2007 Sun finished the process,
making all of Java's core code available under free software / open-source distribution terms,
aside from a small portion of code to which Sun did not hold the copyright.

Primary goals

There were five primary goals in the creation of the Java language:

1. It should be "simple, object oriented, and familiar".

2. It should be "robust and secure".

3. It should be "architecture neutral and portable".

4. It should execute with "high performance".

5. It should be "interpreted, threaded, and dynamic".

Java Platform

Main articles: Java Platform and Java Runtime Environment

One characteristic of Java is portability, which means that computer programs written in the
Java language must run similarly on any supported hardware/operating-system platform.
One should be able to write a program once, compile it once, and run it anywhere.

This is achieved by compiling the Java language code, not to machine code but to Java
bytecode – instructions analogous to machine code but intended to be interpreted by a
virtual machine (VM) written specifically for the host hardware. End-users commonly use a
Java Runtime Environment (JRE) installed on their own machine for standalone Java
applications, or in a Web browser for Java applets.

Standardized libraries provide a generic way to access host specific features such as
graphics, threading and networking. In some JVM versions, bytecode can be compiled to
native code, either before or during program execution, resulting in faster execution.

A major benefit of using bytecode is porting. However, the overhead of interpretation means
that interpreted programs almost always run more slowly than programs compiled to native
executables would, and Java suffered a reputation for poor performance. This gap has been
narrowed by a number of optimization techniques introduced in the more recent JVM
implementations.

One such technique, known as just-in-time (JIT) compilation, translates Java bytecode into
native code the first time that code is executed, then caches it. This results in a program
that starts and executes faster than pure interpreted code can, at the cost of introducing
occasional compilation overhead during execution. More sophisticated VMs also use dynamic
recompilation, in which the VM analyzes the behavior of the running program and selectively
recompiles and optimizes parts of the program. Dynamic recompilation can achieve
optimizations superior to static compilation because the dynamic compiler can base
optimizations on knowledge about the runtime environment and the set of loaded classes,
and can identify hot spots - parts of the program, often inner loops, that take up the most
execution time. JIT compilation and dynamic recompilation allow Java programs to approach
the speed of native code without losing portability.

Another technique, commonly known as static compilation, or ahead-of-time (AOT)

compilation, is to compile directly into native code like a more traditional compiler. Static
Java compilers translate the Java source or bytecode to native object code. This achieves
good performance compared to interpretation, at the expense of portability; the output of
these compilers can only be run on a single architecture. AOT could give Java something
close to native performance, yet it is still not portable since there are no compiler directives,
and all the pointers are indirect with no way to micro manage garbage collection.

Java's performance has improved substantially since the early versions, and performance of
JIT compilers relative to native compilers has in some tests been shown to be quite similar. [12]
[13]
The performance of the compilers does not necessarily indicate the performance of the
compiled code; only careful testing can reveal the true performance issues in any system.

One of the unique advantages of the concept of a runtime engine is that even the most
serious errors (exceptions) in a Java program should not 'crash' the system under any
circumstances, provided the JVM itself is properly implemented. Moreover, in runtime engine
environments such as Java there exist tools that attach to the runtime engine and every
time that an exception of interest occurs they record debugging information that existed in
memory at the time the exception was thrown (stack and heap values). These Automated
Exception Handling tools provide 'root-cause' information for exceptions in Java programs
that run in production, testing or development environments. Such precise debugging is
much more difficult to implement without the run-time support that the JVM offers.

Implementations

Sun Microsystems officially licenses the Java Standard Edition platform for Microsoft
Windows, Linux, Mac OS X, and Solaris. Through a network of third-party vendors and
licensees[14], alternative Java environments are available for these and other platforms.

Sun's trademark license for usage of the Java brand insists that all implementations be
"compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the
Microsoft implementation did not support RMI or JNI and had added platform-specific
features of their own. Sun sued in 1997, and in 2001 won a settlement of $20 million as well
as a court order enforcing the terms of the license from Sun. [15] As a result, Microsoft no
longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot
support Java applets without a third-party plugin. Sun, and others, have made available free
Java run-time systems for those and other versions of Windows.
Platform-independent Java is essential to the Java EE strategy, and an even more rigorous
validation is required to certify an implementation. This environment enables portable
server-side applications, such as Web services, servlets, and Enterprise JavaBeans, as well as
with embedded systems based on OSGi, using Embedded Java environments. Through the
new GlassFish project, Sun is working to create a fully functional, unified open-source
implementation of the Java EE technologies.

Sun also distributes a superset of the JRE called the Java 2 SDK (more commonly known as
the JDK), which includes development tools such as the Java compiler, Javadoc, Jar and
debugger.

Automatic memory management

Java uses an automatic garbage collector to manage memory in the object lifecycle. The
programmer determines when objects are created, and the Java runtime is responsible for
recovering the memory once objects are no longer in use. Once no references to an object
remain, the unreachable object becomes eligible to be freed automatically by the garbage
collector. Something similar to a memory leak may still occur if a programmer's code holds a
reference to an object that is no longer needed, typically when objects that are no longer
needed are stored in containers that are still in use. If methods for a nonexistent object are
called, a "null pointer exception" is thrown.

One of the ideas behind Java's automatic memory management model is that programmers
be spared the burden of having to perform manual memory management. In some
languages memory for the creation of objects is implicitly allocated on the stack, or explicitly
allocated and deallocated from the heap. Either way the responsibility of managing memory
resides with the programmer. If the program does not deallocate an object, a memory leak
occurs. If the program attempts to access or deallocate memory that has already been
deallocated, the result is undefined and difficult to predict, and the program is likely to
become unstable and/or crash. This can be partially remedied by the use of smart pointers,
but these add overhead and complexity.

Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is
guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new
object; this can cause a program to stall momentarily. Where performance or response time
is important, explicit memory management and object pools are often used.

Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned
integers (usually long integers) can be used interchangeably. This allows the garbage
collector to relocate referenced objects, and ensures type safety and security.

As in C++ and some other object-oriented languages, variables of Java's primitive types are
not objects. Values of primitive types are either stored directly in fields (for objects) or on the
stack (for methods) rather than on the heap, as commonly true for objects (but see Escape
analysis). This was a conscious decision by Java's designers for performance reasons.
Because of this, Java was not considered to be a pure object-oriented programming
language. However, as of Java 5.0, autoboxing enables programmers to proceed as if
primitive types are instances of their wrapper classes.

Syntax

Main article: Java syntax

The syntax of Java is largely derived from C++. Unlike C++, which combines the syntax for
structured, generic, and object-oriented programming, Java was built almost exclusively as
an object oriented language. All code is written inside a class and everything is an object,
with the exception of the intrinsic data types (ordinal and real numbers, boolean values, and
characters), which are not classes for performance reasons.

Java suppresses several features (such as operator overloading and multiple inheritance) for
classes in order to simplify the language and to prevent possible errors and anti-pattern
design.

Java uses the same commenting methods as C++. There are two different methods of
commenting, the first is generally used for single line comments // two forward slashes and
the second is generally used for multiple line commenting, this requires an open and close.
In order to use the second method of commenting you must use the forward slash asterisk
(/*) and it must end with an asterisk forward slash (*/)

Features of JAVA

Simple
Java was designed to be easy for the professional programmer to learn and use effectively.
Assuming that we have some programming experience we will not find Java hard to master
and it inherits c/c++ syntax it is simple to work with.

Secure
Prior to java, most users did not download executable programs frequently and those who
did scan them from viruses prior to execution. In addition to viruses another type of
malicious program exists that must be guarded against. This type of program must be
guarded against. This type of program can gather private information, such as credit card
numbers and passwords by searching the contents of our local file system. Java answers
both these concerns by providing the firewall between a network application and our
computer. Java achieves this protection by confining a java program to the Java execution
environment and not allowing it access to others part of the computer.

Portable
Many types of computers and operating systems are in use throughout the world and many
are connected to the internet. For programs to be dynamically downloaded to all the various
types of platforms connected to the internet ,some means of generating portable executable
code is needed. It is provided by the byte code information and execution on the Java virtual
machine.

Robust
The multiplatform environment of Web places extraordinary demands on a program ,
because the program must execute in a variety of systems . Consider two of the main
reasons of the program failure: memory management and mishandle exceptional conditions.
Java virtually eliminates these problems by managing memory allocation and deal location
itself. It also helps in exception handling.
Multithreaded
Java was designed to meet the real world requirement of creating interactive networked
programs. To accomplish this, Java supports multithreaded programming, which allows us to
write programs that do many things simultaneously.

Dynamic
Java programs carry with them substantial amount of run time type information that is used
to verify and resolve accesses to objects at run time. Thos makes it possible dynamically link
code in a safe and expedient manner.

Interpreted and High Performance

Java enables the creation of cross platform programs by compiling into an intermediate
representation called java byte codes. This code can be interpreted on any system that
provides the java virtual machine. This byte code is carefully designed so that it would be
easy to translate directly into the machine codes for high performance by using the Just- In –
Time compiler.

Java Swing
Example Swing widgets in Java 5 for the X Window System

Swing is a widget toolkit for Java. It is part of Sun Microsystems' Java Foundation Classes
(JFC) — an API for providing a graphical user interface (GUI) for Java programs.

Swing was developed to provide a more sophisticated set of GUI components than the
earlier Abstract Window Toolkit. Swing provides a native look and feel that emulates the look
and feel of several platforms, and also supports a pluggable look and feel that allows
applications to have a look and feel unrelated to the underlying platform .

Architecture

Swing is a platform-independent, Model-View-Controller GUI framework for Java. It follows a

single-threaded programming model, and possesses the following traits:

Foundations

Platform independence

Swing is platform independent both in terms of its expression (Java) and its implementation
(non-native universal rendering of widgets).

Extensibility

Swing is a highly partitioned architecture, which allows for the "plugging" of various custom
implementations of specified framework interfaces: Users can provide their own custom
implementation(s) of these components to override the default implementations. In general,
Swing users can extend the framework by extending existing (framework) classes and/or
providing alternative implementations of core components.

Component-oriented

Swing is a component-based framework. The distinction between objects and components is

a fairly subtle point: concisely, a component is a well-behaved object with a known/specified
characteristic pattern of behaviour. Swing objects asynchronously fire events, have "bound"
properties, and respond to a well-known set of commands (specific to the component.)
Specifically, Swing components are Java Beans components, compliant with the Java Beans
Component Architecture specifications.
Customizable

Given the programmatic rendering model of the Swing framework, fine control over the
details of rendering of a component is possible in Swing. As a general pattern, the visual
representation of a Swing component is a composition of a standard set of elements, such as
a "border", "inset", decorations, etc. Typically, users will programmatically customize a
standard Swing component (such as a JTable) by assigning specific Borders, Colors,
Backgrounds, opacities, etc., as the properties of that component. The core component will
then use these property (settings) to determine the appropriate renderers to use in painting
its various aspects. However, it is also completely possible to create unique GUI controls
with highly customized visual representation.

Configurable

Swing's heavy reliance on runtime mechanisms and indirect composition patterns allows it
to respond at runtime to fundamental changes in its settings. For example, a Swing-based
application can change its look and feel at runtime. Further, users can provide their own look
and feel implementation, which allows for uniform changes in the look and feel of existing
Swing applications without any programmatic change to the application code.

Lightweight UI

Swing's configurability is a result of a choice not to use the native host OS's GUI controls for
displaying itself. Swing "paints" its controls programmatically through the use of Java 2D
APIs, rather than calling into a native user interface toolkit. Thus, a Swing component does
not have a corresponding native OS GUI component, and is free to render itself in any way
that is possible with the underlying graphics APIs.

However, at its core every Swing component relies on an AWT container, since (Swing's)
JComponent extends (AWT's) Container. This allows Swing to plug into the host OS's GUI
management framework, including the crucial device/screen mappings and user
interactions, such as key presses or mouse movements. Swing simply "transposes" its own
(OS agnostic) semantics over the underlying (OS specific) components. So, for example,
every Swing component paints its rendition on the graphic device in response to a call to
component.paint(), which is defined in (AWT) Container. But unlike AWT components, which
delegated the painting to their OS-native "heavyweight" widget, Swing components are
responsible for their own rendering.

This transposition and decoupling is not merely visual, and extends to Swing's management
and application of its own OS-independent semantics for events fired within its component
containment hierarchies. Generally speaking, the Swing Architecture delegates the task of
mapping the various flavors of OS GUI semantics onto a simple, but generalized, pattern to
the AWT container. Building on that generalized platform, it establishes its own rich and
complex GUI semantics in the form of the JComponent model. A review of the source of
Container java and JComponent java classes is recommended for further insights into the
nature of the interface between Swing's lightweight components and AWT's heavyweight
widgets.

Loosely-Coupled/MVC

The Swing library makes heavy use of the Model/View/Controller software design pattern,
which conceptually decouples the data being viewed from the user interface controls
through which it is viewed. Because of this, most Swing components have associated
models (which are specified in terms of Java interfaces), and the programmer can use
various default implementations or provide their own. The framework provides default
implementations of model interfaces for all of its concrete components. [1]

Typically, Swing component model objects are responsible for providing a concise interface
defining events fired, and accessible properties for the (conceptual) data model for use by
the associated JComponent. Given that the overall MVC pattern is a loosely-coupled
collaborative object relationship pattern, the model provides the programmatic means for
attaching event listeners to the data model object. Typically, these events are model centric
(ex: a "row inserted" event in a table model) and are mapped by the JComponent
specialization into a meaningful event for the GUI component.

For example, the JTable has a model called TableModel that describes an interface for how a
table would access tabular data. A default implementation of this operates on a two-
dimensional array.

The view component of a Swing J Component is the object used to graphically "represent"
the conceptual GUI control. A distinction of Swing, as a GUI framework, is in its reliance on
programmatically-rendered GUI controls (as opposed to the use of the native host OS's GUI
controls). Prior to Java 6 Update 10, this distinction was a source of complications when
mixing AWT controls, which use native controls, with Swing controls in a GUI (see Mixing
AWT and Swing components).

Finally, in terms of visual composition and management, Swing favors relative layouts (which
specify the positional relationships between components) as opposed to absolute layouts
(which specify the exact location and size of components). This bias towards "fluid"' visual
ordering is due to its origins in the applet operating environment that framed the design and
development of the original Java GUI toolkit. (Conceptually, this view of the layout
management is quite similar to that which informs the rendering of HTML content in
browsers, and addresses the same set of concerns that motivated the former.)

Look and feel

Swing allows one to specialize the look and feel of widgets, by modifying the default (via
runtime parameters), deriving from an existing one, by creating one from scratch, or,
beginning with J2SE 5.0, by using the skinnable synth Look and Feel (see Synth Look and
Feel), which is configured with an XML property file. The look and feel can be changed at
runtime, and early demonstrations of Swing frequently provided a way to do this.

Relationship to AWT
AWT and Swing class hierarchy

Since early versions of Java, a portion of the Abstract Window Toolkit (AWT) has provided
platform-independent APIs for user interface components. In AWT, each component is
rendered and controlled by a native peer component specific to the underlying windowing
system.

By contrast, Swing components are often described as lightweight because they do not
require allocation of native resources in the operating system's windowing toolkit. The AWT
components are referred to as heavyweight components.

Much of the Swing API is generally a complementary extension of the AWT rather than a
direct replacement. In fact, every Swing lightweight interface ultimately exists within an AWT
heavyweight component because all of the top-level components in Swing (JApplet, JDialog,
JFrame, and JWindow) extend an AWT top-level container. However, the use of both
lightweight and heavyweight components within the same window is generally discouraged
due to Z-order incompatibilities.

The core rendering functionality used by Swing to draw its lightweight components is
provided by Java 2D, another part of JFC.

Relationship to SWT

The Standard Widget Toolkit (SWT) is a competing toolkit originally developed by IBM and
now maintained by the Eclipse Foundation. SWT's implementation has more in common with
the heavyweight components of AWT. This confers benefits such as more accurate fidelity
with the underlying native windowing toolkit, at the cost of an increased exposure to the
native platform in the programming model.

The advent of SWT has given rise to a great deal of division among Java desktop developers,
with many strongly favoring either SWT or Swing. Sun's development on Swing continues to
focus on platform look and feel (PLAF) fidelity with each platform's windowing toolkit in the
approaching Java SE 7 release (as of December 2006).

There has been significant debate and speculation about the performance of SWT versus
Swing; some hinted that SWT's heavy dependence on JNI would make it slower when the GUI
component and Java need to communicate data, but faster at rendering when the data
model has been loaded into the GUI. However, benchmarks show no clear winner, and the
results greatly depend on the context and the environments .

SWT serves the Windows platform very well but is considered by some to be less effective as
a technology for cross-platform development. By using the high-level features of each native
windowing toolkit, SWT returns to the issues seen in the mid 90's (with toolkits like zApp,
Zinc, XVT and IBM/Smalltalk) where toolkits attempted to mask differences in focus
behaviour, event triggering and graphical layout. Failure to match behavior on each platform
can cause subtle but difficult-to-resolve bugs that impact user interaction and the
appearance of the GUI.

Debugging

Swing application debugging can be difficult because of the toolkit's visual nature.

Problem

In contrast to non-visual applications, GUI applications cannot be as easily debugged using

step-by-step debuggers. One of the reasons is that Swing normally performs painting into an
off-screen buffer (double buffering) first and then copies the entire result to the screen. This
makes it impossible to observe the impact of each separate graphical operation on the user
interface using a general-purpose Java debugger. It is possible to turn off the double
buffering using the API, and by using the Java default Look and Feel, it is also possible to turn
on Debug Graphics, which makes each drawing operations flash. Another problem is that GUI
applications typically ends up being somewhat multi-threaded, in that the drawing takes
place on the event dispatch thread, while longer-running operations typically are sent of to
other threads. However, this is typically not worse than for web applications, and current
debuggers found in modern IDEs are rather good at handling many threads visually efficient.

Swing Explorer

A very good tool for Swing debugging is the Swing Explorer written by Maxim Zakharenkov.
One use this tool by starting the application to be explored through the Swing Explorer
application. The Swing Explorer window appears, and then the application appears as
normal, only that Swing Explorer captures every drawing event being performed. The top-
level windows of the application are then enumerated in the Swing Explorer window, letting
the developer select which one to explore. She will then get a copy of the window inside
Swing Explorer. It is possible to magnify this representation, getting a good view of every
pixel. She may view the window's drawing area decomposed much like good web browsers
make it possible to visually inspect web pages' DOM tree. The Swing Explorer application
furthermore makes it possible to "replay" every single drawing stroke and at the same time
have the IDE be linked up and show the line of code that performed that particular drawing
operation. Or, opposite, on the final image, one can click on a pixel, and thus being pointed
to the code that lastly touched that pixel.

A basic example
The following is a rather simple Swing-based program. It displays window (a JFrame)
containing a label and a button. The example will compile cleanly if put in a file
com/example/SwingExample.java

package com.example;

// Import the swing and AWT classes needed

import java.awt.EventQueue;
import java.awt.FlowLayout;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.WindowConstants;

/**
* Basic Swing example.
*/
public class SwingExample {
public static void main(String[] args) {

// Make sure all Swing/AWT invocations are done on the Event Dispatch
Thread (EDT)
EventQueue.invokeLater(new Runnable() {
@Override
public void run() {
// Create a JFrame, which is a Window with "decorations",
i.e. title, border and close-button
JFrame f = new JFrame("Swing Example Window");

// Set a simple Layout Manager that arranges the contained

Components
f.setLayout(new FlowLayout());

// Add some Components

f.add(new JLabel("Hello world!"));
f.add(new JButton("Press me!"));

// "Pack" the window, making it "just big enough".

f.pack();

// Set the default close operation for the window, or else

the program won't exit when clicking close button
// (The default is HIDE_ON_CLOSE, which just makes the
window invisible)
f.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);

// Set the visibility as true, thereby displaying it

f.setVisible(true);
}
});
}
}

JDBC
 JDBC is an API for the Java programming language
that defines how a client may access a database. It
provides methods for querying and updating data in a
database. JDBC is oriented towards relational
Oracle Datatype setXXX() databases.

The Java 2 Platform, Standard Edition, version 1.4

(J2SE) includes the JDBC 3.0 API[1] together with a
CHAR setString() reference implementation JDBC-to-ODBC bridge,
enabling connections to any ODBC-accessible data
source in the JVM host environment. This bridge is
native code (not Java), closed source, and only
VARCHAR2 setString()
appropriate for experimental use and for situations in
which no other driver is available,[2] not least because
it provides only a limited subset of the JDBC 3.0 API, as
setBigDecimal() it was originally built and shipped with JDBC 1.0 for
use with old ODBC v2.0 drivers (ODBC v3.0 was
released in 1996
setBoolean()
Overview

JDBC has been part of the Java Standard Edition since

setByte()
the release of JDK 1.1. The JDBC classes are contained
in the Java package java.sql. Starting with version 3.0,
JDBC has been developed under the Java Community
setShort() Process. JSR 54 specifies JDBC 3.0 (included in J2SE
1.4), JSR 114 specifies the JDBC Rowset additions, and
NUMBER JSR 221 is the specification of JDBC 4.0
setInt()
JDBC allows multiple implementations to exist and be
used by the same application. The API provides a
mechanism for dynamically loading the correct Java
setLong() packages and registering them with the JDBC Driver
Manager. The Driver Manager is used as a connection
factory for creating JDBC connections.
setFloat()

setDouble()

INTEGER setInt()

FLOAT setDouble()

CLOB setClob()

BLOB setBlob()

RAW setBytes()
JDBC connections support creating and executing statements. These may be update
statements such as SQL's CREATE, INSERT, UPDATE and DELETE, or they may be query
statements such as SELECT. Additionally, stored procedures may be invoked through a JDBC
connection. JDBC represents statements using one of the following classes:

 Statement – the statement is sent to the database server each and every time.
 PreparedStatement – the statement is cached and then the execution path is pre
determined on the database server allowing it to be executed multiple times in an
efficient manner.

 CallableStatement – used for executing stored procedures on the database.

Update statements such as INSERT, UPDATE and DELETE return an update count that
indicates how many rows were affected in the database. These statements do not return any
other information.

Query statements return a JDBC row result set. The row result set is used to walk over the
result set. Individual columns in a row are retrieved either by name or by column number.
There may be any number of rows in the result set. The row result set has metadata that
describes the names of the columns and their types.

Here are examples of host database types which Java can convert to with a function.

For an example of a CallableStatement (to call stored procedures in the database), see the
JDBC API Guide.

JDBC Drivers

JDBC Drivers are client-side adaptors (they are installed on the client machine, not on the
server) that convert requests from Java programs to a protocol that the DBMS can
understand.

Types
There are commercial and free drivers available for most relational database servers. These
drivers fall into one of the following types:

 Type 1, the JDBC-ODBC bridge driver

 Type 2, the Native-API driver

 Type 3, the JDBC net pure-java driver

 Type 4, the native-protocol pure-java driver

Internal JDBC driver, driver embedded with JRE in Java-enabled SQL databases. Used for Java
stored procedures. This does not belong to the above classification, although it would likely
be either a type 2 or type 4 driver (depending on whether the database itself is
implemented in Java or not). An example of this is the KPRB driver supplied with Oracle
RDBMS. "jdbc:default:connection" is a relatively standard way of referring making such a
connection (at least Oracle and Apache Derby support it). The distinction here is that the
JDBC client is actually running as part of the database being accessed, so access can be
made directly rather

Sources
 SQLSummit.com publishes list of drivers, including JDBC drivers and vendors
 Sun Microsystems provides a list of some JDBC drivers and vendors

 Simba Technologies ships an SDK for building custom JDBC Drivers for any
custom/proprietary relational data source

 DataDirect Technologies provides a comprehensive suite of fast Type 4 JDBC drivers

for all major database

 IDS Software provides a Type 3 JDBC driver for concurrent access to all major
databases. Supported features include resultset caching, SSL encryption, custom
data source, dbShield.

 OpenLink Software ships JDBC Drivers for a variety of databases, including Bridges to
other data access mechanisms (e.g., ODBC, JDBC) which can provide more
functionality than the targeted mechanism

 JDBaccess is a Java persistence library for MySQL and Oracle which defines major
database access operations in an easy usable API above JDBC

 JNetDirect provides a suite of fully Sun J2EE certified high performance JDBC drivers.

 HSQL is a RDBMS with a JDBC driver and is available under a BSD license.

A file system allows an application to save information in a very static manner. A database is
an application that specializes in providing other applications with access to data in a more
complex manner than is allowed by file systems.

JAVA Database Connectivity:

JDBC is a Java API for executing SQL statements. It consists of a set of classes and interface
written in Java programming language.
Using JDBC, it is easy to send SQL statements to virtually any relational database.
One can write a single program using JDBC API, and the program will be able to send SQL
statements to the appropriate database and with an application written in the Java
programming language. The combination of Java and JDBC has a facility that writes it once
and run it anywhere.

JDBC Model Support

The JDBC API supports both two-tier and three-tire models for database access. JDBC is
important to allow database access from a java middle tier.

ORACLE DATABASE:
An Oracle database is a collection of three types of physical disk file, all of which are binary
in nature, and use a proprietary unique-to-Oracle internal format, such that only an Oracle
instance can open, read from, write to and generally understand their contents:
Data files, in which tables, indexes, undo segments and other stores of data actually reside.
Online Redo Logs, in which a data change history is kept.
Control Files, which store the physical location of all the data files and online redo logs, along
with a lot of internal information necessary for keeping the database healthy and functional.

Other files which are vital for the correct operation of an Oracle database are not technically
part of the database at all:
Password file -a small binary file that records details of who is permitted to startup,
shutdown, backup, recover or create a database (”Privileged Users”)
Archived Redo Logs -copies of the online redo logs periodically taken by the server itself. The
online logs are finite in number and size, so there is a limit to how many data changes they
can record before filling up (at which point they overwrite the oldest changes). Therefore,
archiving them is the only way of recording all data changes, theoretically for ever: archives
are not limited in number, but only by the amount of physical storage needed to house
them.
Init.ora -a small text file that contains a set of parameters that govern the way the database
behaves, and sizes the memory structures (the Instance needed to manage and access the
database.
Spfile.ora -a small binary version or copy of the init.ora. The spfile is only available for
version 9i and later databases. Being a binary file, the database can itself edit the file, and is
thus able to tune and configure itself to some extent and make the configuration changes it
thereby makes persistent between instance startups.

The difference between the two groups of file is that if you lose one of the ‘true’ database
files (by corrupting it, for example), the database will almost immediately know about it,
complain about it and will quite possibly crash as a result of it. Lose a password file, an
archived redo log or an init.ora/spfile.ora, however, and no-one will know that it’s been lost
until the next time you try to startup the instance, or recover the database or perform some
similar database administration type of task.

MICROSOFT ACCESS:
MS - Access includes help for the following : Visual Basic Applications (VBA) modules ,
functions , syntax , and basic principles when you develop for Microsoft Office programs;
external database connectivity issues associated with drivers and technologies that are
packaged with Microsoft products and installation and configuration of server extensions on
a Microsoft Windows NT version 4.0 Server or Windows 2000 Server, or Microsoft Internet.

Tables
A table is a collection of data about a specific topic, such as products or suppliers. Using a
separate table for each topic means that we can store that data only once, which makes
your database more efficient, and reduces data-entry errors.

MS-Access Database
Microsoft access database is a collection of data and objects related to a particular topic or
purpose. A Microsoft access database may contain tables, queries, forms, reports, macros,
modules and shortcuts to data access pages. The Microsoft Jet database engine manages
data in tables that reside in the database. Data in linked tables may reside in another Access
database, in an external data source such as dbase or Microsoft Excel, or in an ODBC data
source such as Microsoft SQL Server.
MICROSOFT SQL SERVER
It is a _ HYPERLINK
"http://en.wikipedia.org/wiki/Relational_database_management_system" \o "Relational
database management system" _relational database management system_ (RDBMS)
produced by _ HYPERLINK "http://en.wikipedia.org/wiki/Microsoft" \o "Microsoft" _Microsoft_.
Its primary query language is _ HYPERLINK "http://en.wikipedia.org/wiki/Transact-SQL" \o
"Transact-SQL" _Transact-SQL_, an implementation of the ANSI/ISO standard Structured
Query Language (_ HYPERLINK "http://en.wikipedia.org/wiki/SQL" \o "SQL" _SQL_) used by
both Microsoft and Sybase. SQL Server is commonly used by businesses for small- to
medium-sized databases, but the past five years have seen greater adoption of the product
for larger enterprise databases.

SOFTWARE REQUIREMENTS SPECIFICATION:

DEFINITION:
A set of precisely stated properties or constraints which a software system must satisfy.
A software requirements document establishes boundaries on the solution space of the
problem of developing a useful software system.
A software requirements document allows a design to be validated - if the constraints and
properties specified in the document are satisfied by the software design, then that design is
an acceptable solution to the problem.
Software Requirements Specification (SRS) is a complete description of the behavior of the
system to be developed. It includes a set of _HYPERLINK
"http://en.wikipedia.org/wiki/Use_cases" \o "Use cases"_use cases_ that describe all of the
interactions that the users will have with the software. Use cases are also known as
_HYPERLINK "http://en.wikipedia.org/wiki/Functional_requirements" \o "Functional
requirements"_functional requirements_. In addition to use cases, the SRS also contains
nonfunctional requirements. _HYPERLINK "http://en.wikipedia.org/wiki/Non-
functional_requirements" \o "Non-functional requirements"_Non-functional requirements_ are
requirements which impose constraints on the design or implementation (such as
_HYPERLINK "http://en.wikipedia.org/wiki/Performance_engineering" \o "Performance
engineering"_performance engineering_ requirements, _HYPERLINK
"http://en.wikipedia.org/wiki/Quality" \o "Quality"_quality_ standards, or design constraints).
In _HYPERLINK "http://en.wikipedia.org/wiki/Systems_engineering" \o "Systems
engineering"_systems engineering_ and _HYPERLINK
"http://en.wikipedia.org/wiki/Software_engineering" \o "Software engineering"_software
engineering_, requirements analysis encompasses those tasks that go into determining the
requirements of a new or altered system, taking account of the possibly conflicting
requirements of the various stakeholders, such as users. Requirements analysis is critical to
the success of a project.
Systematic requirements analysis is also known as requirements engineering. It is
sometimes referred to loosely by names such as requirements gathering, requirements
capture, or requirements specification. The term "requirements analysis" can also be applied
specifically to the analysis proper.

CHARACTERISTICS OF SOFTWARE REQUIREMENT SPECIFICATION:

Unambiguous:
Every requirement has only one interpretation.
Each characteristic of the final product is described using a single unique term.
A glossary should be used when a term used in a particular context could have multiple
meanings.
Complete:
A complete SRS must possess the following qualities:
inclusion of all significant requirements,
definition of the responses of the software to all realizable classes of input,
conformity to any standard that applies to it,
Full labeling and referencing of all tables and diagrams and the definition of all terms.
Verifiable:
Every requirement must be verifiable.
There must exist some finite cost-effective process with which a person or machine can
check that the software meets the requirement.

Consistent:
No set of individual requirements described in the SRS can be in conflict.
Types of likely conflicts:
Two or more requirements describe the same real world object in different terms.
The specified characteristics of real world objects might conflict.
There may be a logical or temporal conflict between two specified actions.
Modifiable:
The structure and style of the SRS are such that any necessary changes to the requirements
can be made easily, completely and consistently.
Requirements:
A coherent and easy-to-use organization (including a table of contents, index and cross-
referencing)
Not be redundant - this can lead to errors.
Traceable:
The origin of each requirement must be clear.
The SRS should facilitate the referencing of each requirement in future development or
enhancement documentation.
Types:
Backward traceability
Each requirement must explicitly reference its source in previous documents.
Forward traceability
Each requirement must have an unique name or reference number.

COMPONENTS OF SRS(SOFTWARE REQUIREMENT SPECIFICATION)

Functionality:

Functional requirement specify which output should be produced from given inputs. They
describe the relationship between the input and output of the system. For functional
requirement, a detailed description of all the data inputs and their source, the unit of
measure, and the range of valid inputs must be specified. In our Project Basically there is no
Database & we are performing mainly two types of operations viz Sending & Receiving ,
therefore we are showing Functional Requirement in the form of Structural chart ,which
specify basic operation performed.

Performance:
This part of SRS specifies the performance constraints on the software system. There are
two type of performance requirements:

Static Requirement-
They are those that do not impose constraints on execution characteristic of system. They
are also called capacity requirement of the system. These include number of users
supported, number of terminals supported.

Dynamic requirement-
They specify constraints on the execution behavior of the system.They include response
time and throughput constraints on the system.

DESIGNING:

Software design is a process of problem-solving and planning for a solution. After the
purpose and specifications of software is determined "Software developer"_software
developers_ will design or employ to develop a plan for a solution.

SOFTWARE TESTING:
INRODUCTION:
Software Testing is the process used to help identify the correctness, completeness.Testing is
a process of technical investigation, performed on behalf of stakeholders, that is intended to
reveal quality-related information about the product with respect to the context in which it is
intended to operate.
There are many approaches to software testing, but effective testing of complex products is
essentially a process of investigation, not merely a matter of creating and following routine
procedure.
One definition of testing is "the process of questioning a product in order to evaluate it",
where the "questions" are operations the tester attempts to execute with the product, and
the product answers with its behavior in reaction to the probing of the tester.

TESTING VS. QUALITY ASSURANCE:

Quality Assurance is the process of making sure that the customers gets enough of what
they pay for to satisfy their needs. Testing is the means by which we perform the process.
You can test without assuring quality, but you can't assure quality without testing. A
common problem with software quality is that the assurance is in the hands of the
producers. While the producers can certainly create and perform insightful, powerful tests, it
is perfectly possible to design tests that will churn away forever and never discover a defect.
This is the psychological temptation when the software producers program tests to evaluate
themselves.
Structural (usually called “white box”) testing and functional ("black box") testing have
unique characteristics, advantages and limitations that make them more or less applicable
to certain stages of test.
SOFTWARE TESTING STRATEGIES:
To perform effective Testing, a software team should conduct effective formal technical
reviews. By doing this, many errors will be eliminated before testing commences.
Testing begins at the component level and works “outward” towards the integration of the
entire computer based system.
Different testing techniques are appropriate at different points in time.
Testing is conducted by the developer of the software and (for large projects) an
independent test group.
Testing and debugging are different activities, but debugging must be accommodated in any
testing strategy.

TESTING PROCESS:

TEST CASE DESIGN:

Black Box Testing:
Black box testing takes an external perspective of the test object to derive test cases. These
tests can be functional or non-functional, though usually functional. The test designer
selects valid and invalid input and determines the correct output. There is no knowledge of
the test object's internal structure.
This method of test design is applicable to all levels of _HYPERLINK
"http://en.wikipedia.org/wiki/Software_testing" \o "Software testing"_software testing_:
_HYPERLINK "http://en.wikipedia.org/wiki/Unit_test" \o "Unit test"_unit_, _HYPERLINK
"http://en.wikipedia.org/wiki/Integration_testing" \o "Integration testing"_integration_,
functional testing, _HYPERLINK "http://en.wikipedia.org/wiki/System_testing" \o "System
testing"_system_ and _HYPERLINK "http://en.wikipedia.org/wiki/Acceptance_test" \o
"Acceptance test"_acceptance_. The higher the level, and hence the bigger and more
complex the box, the more one is forced to use black box testing to simplify. While this
method can uncover unimplemented parts of the specification, one cannot be sure that all
existent paths are tested. Black box tests better address the modern programming
paradigm. As object-oriented programming, automatic code generation and code re-use
becomes more prevalent, analysis of source code itself becomes less important and
functional tests become more important. Black box tests also better attack the quality
target. Since only the people paying for an application can determine if it meets their needs,
it is an advantage to create the quality criteria from this point of view from the beginning.
Black box tests have a basis in the scientific method. Like the process of science, functional
tests must have a hypothesis (your specifications), a defined method or procedure (your
test), reproducible components (your test data), and a standard notation to record the
results.

White Box Testing:

White box testing (clear box testing, glass box testing or structural testing) uses an internal
perspective of the system to design test cases based on internal structure. It requires
programming skills to identify all paths through the software. The tester chooses test case
inputs to exercise paths through the code and determines the appropriate outputs.
In electrical hardware, testing every node in a circuit may be probed and measured; an
example is _HYPERLINK "http://en.wikipedia.org/w/index.php?title=In-
circuit_testing&action=edit" \o "In-circuit testing"_in-circuit testing_ (ICT).

Since the tests are based on the actual implementation, if the implementation changes, the
tests may also change.
For example ICT needs updates if component values change, and needs modified/new
fixture if the circuit changes. This adds financial resistance to the change process, thus
buggy products may stay buggy. _HYPERLINK
"http://en.wikipedia.org/wiki/Automated_optical_inspection" \o "Automated optical
inspection"_Automated optical inspection_ (AOI) offers similar component level correctness
checking without the cost of ICT fixtures; however changes still require test updates.

While white box testing is applicable at the _HYPERLINK

"http://en.wikipedia.org/wiki/Unit_testing" \o "Unit testing"_unit_, _HYPERLINK
"http://en.wikipedia.org/wiki/Integration_testing" \o "Integration testing"_integration_ and
_HYPERLINK "http://en.wikipedia.org/wiki/System_testing" \o "System testing"_system_ levels
of the _HYPERLINK "http://en.wikipedia.org/wiki/Software_testing" \o "Software
testing"_software testing_ process, it's typically applied to the unit. So while it normally tests
paths within a unit, it can also test paths between units during integration, and between
subsystems during a system level test. Though this method of test design can uncover an
overwhelming number of test cases, it might not detect unimplemented parts of the
specification or missing requirements. But you can typical white box test design techniques
include:
_HYPERLINK "http://en.wikipedia.org/wiki/Control_flow" \o "Control flow"_Control flow_ testing
Data flow testing
Using white box testing approaches, the software engineering can produce test cases that
(i) Guarantee that all independent paths in a module have been exercised at least once
(ii) Exercise all logical decisions
(iii) Execute all loops at their boundaries and in their operational bounds
(iv) Exercise internal data structures to maintain their validity.

TEST EXECUTION:
Unit Testing:
In computer programming, unit testing is a procedure used to validate that individual units
of source code are working properly. A unit is the smallest testable part of an application. In
procedural programming a unit may be an individual program, function, procedure etc, while
in object-oriented programming, the smallest unit is always a Class; which may be a
base/super class, abstract class or derived/child class. Units are distinguished from modules
in that modules are typically made up of units.
The goal of unit testing is to isolate each part of the program and show that the individual
parts are correct. A unit test provides a strict, written contract that the piece of code must
satisfy. As a result, it affords several benefits:

Facilitates change:
Unit testing allows the programmer to refractor the code at a later date, and make sure the
module still works correctly (i.e. regression testing). The procedure is to write test cases for
all functions and methods so that whenever a change causes a fault, it can be quickly
identified and fixed.
Readily-available unit tests make it easy for the programmer to check whether a piece of
code s still working properly. Good unit test design produces test cases that cover all paths
through the unit with attention paid to loop conditions.

Simplifies integration:
Unit testing helps to eliminate uncertainty in the units themselves and can be used in a
bottom-up testing style approach. By testing the parts of a program first and then testing
the sum of its parts,
integration testing becomes much easier.
 Documentation:
Unit testing provides a sort of "living document". Clients and other developers looking to
learn how to use the module can look at the unit tests to determine how to use the module
to fit their needs and gain a basic understanding of the API.Unit test cases embody
characteristics that are critical to the success of the unit. These characteristics can indicate
appropriate/inappropriate use of a unit as well as negative behaviors that are to be trapped
by the unit.

Integration Testing:
Integration testing is the phase of software testing in which individual software modules are
combined and tested as a group. It follows unit testing and precedes system
testing.Integration testing takes as its input modules that have been unit tested, groups
them in larger aggregates, applies tests defined in an integration test plan to those
aggregates, and delivers as its output the integrated system ready for system testing. The
purpose of integration testing is to verify functional, performance and reliability
requirements placed on major design items. These "design items", i.e. assemblages (or
groups of units), are exercised through their interfaces using black box testing, success and
error cases being simulated via appropriate parameter and data inputs.

System Testing:
System testing is testing conducted on a complete, integrated system to evaluate the
system's compliance with its specified requirements. System testing falls within the scope of
black box testing, and as such, should require no knowledge of the inner design of the code
or logic.
As a rule, system testing takes, as its input, all of the "integrated" software components that
have successfully passed integration testing and also the software system itself integrated
with any applicable hardware system(s). The purpose of integration testing is to detect any
inconsistencies between the software units that are integrated together (called
assemblages) or between any of the assemblages and the hardware. System testing is a
more limiting type of testing; it seeks to detect defects both within the "inter-assemblages"
and also within the system as a whole.

SYSTEM REQUIREMENTS:

Hardware requirement:
HDD : 80GB
RAM : 256MB
CD-ROM : 48x
Clock speed : 450MHz
CPU : Pentium 3 or above

Software Requirement:

Front End Tool : JSDK2.0

Language : Java
Back End Tool : Oracle, MS-Access, SQL Server
Operating System : Windows 98, Windows Xp

MODEL USED:

Waterfall Model:
The waterfall model is a "Software development model (a process for the creation of
software) in which development is seen as flowing steadily downwards (like a waterfall)
through the phases of model.
To follow the waterfall model, one proceeds from one phase to the next in a purely
sequential manner. For example, one first completes "requirements specification" — they set
in stone the requirements of the software. When and only when the requirements are fully
completed, one proceeds to design. The software in question is designed and a "blueprint" is
drawn for implementers (coders) to follow — this design should be a plan for implementing
the requirements given. When and only when the design is fully completed, an
implementation of that design is made by coders.
Towards the later stages of this implementation phase, disparate software components
produced by different teams are integrated. After the implementation and integration
phases are complete, the software product is tested and debugged; any faults introduced in
earlier phases are removed here. Then the software product is installed, and later
maintained to introduce new functionality and remove bugs.
Thus the waterfall model maintains that one should move to a phase only when its
preceding phase is completed and perfected. Phases of development in the waterfall model
are thus discrete, and there is no jumping back and forth or overlap between them.

Information Gathering:
Information Gathering and analysis tools have been organized here into eight categories of
tool use. While these categories do not describe the decision process itself, they identify
important inputs to environmental decision-making. Although displayed sequentially as
components of a flow diagram, each of these categories can be undertaken in different
ways, at different points in time, and by different participants in a decision-making process.
In addition, three other steps--identifying the problem, identifying options, and making the
decision--are critical to the decision process, but they don't necessarily entail information
gathering and analysis tools.

The purpose of using these eight categories of decision-aiding tools is to help you arrive at
an effective and balanced decision by collecting and analyzing information systematically.
Information gathered using tools within one category can be integrated with information
obtained at other points in the process. In this way, tentative decisions can be modified
early on, as more information is acquired.
ADVANTAGES:-

Reusability

Understandability

Robustness

Time Effectiveness

LIMITATIONS:

This project will run properly if and only if the databases used by the project are installed
on the system on which the project is running.

Software gets slow when database is used.

Whenever new technology and new database is launched, it is necessary to modify some
part of program within project requires maintenance at that time.

It is very difficult to handle this project by those users who have no knowledge of database
management.

CONCLUSION:
All the material that we have referred so far conclude that this project facilitates the user to
view and access the data from preferred database to other.

Advantage of this project is to provide means of transfer of data from one database to
another.It saves manual work of users.

BIBLIOGRAPHY:
Developing Java Servlets – James Goodwill

Complete Reference in Java - Herbert Nesfield & James Gosling

Software Engineering – Roger S. Pressman

Java Tutorial -- SUN MICROSYSTEM

JDBC Complete -- TechMedia

Server Side Programming – Wrox Publication