This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Bug tracking system provides the job only in some of the large software development companies for many years. Most of the other development companies simply relied on shared lists and emails to the monitor, the status of defects and never make an effort with bug tracking at all. This method is likely to cause those bugs to decide less important by developers to be dropped or ignored and this method is error prone.
After the software is developed, it is given to the tester to test for the bugs. The tester is responsible for finding and reporting of bugs, to project manager. When tester encounters a large number of bugs, all of them may not be reported because of human errors or because of the poor communication within a team.
Bug tracking system is the perfect or unique solution to track the bugs of a solution, product or an application. Bug tracking system admits single or set of developers to continue track of not finished bugs in their product successfully. Bug tracking system can also call as defect tracking system (DTS). For good performance the bug tracking system can increase a lot, the accountability and productivity of single employees by giving a positive feedback and back up the workflow. The bug tracking software allows or group of testers or individual testers to keep path of unfixed bugs in their software successfully. The Bug tracking software can track bugs, can handle code changes, can share information with teammates, submit and review connects and control standard assurance.
1.2 Need of Study:
Bug Tracking System is the process of reporting and tracking the process of bugs. It is important to manage the management of bugs, frequently firms find that projects getting out of hand because of bugs are being developed from different sources to different team members and no one can really be confident about the bugs which are present, and which one have been fixed.
1.3 Objects and goals:
A tester or quality analyst records the bugs when a defect or bug is found, and the required steps are taken to copy it. A programmer will then repair the bug and inform to the tester about the bug which has been fixed. The tester will then examine the bug has really fixed or not, if fixed he closes the bug, If not he does not change the state of the bug in the database. The project manager will receive bug which is send by the system. The project manager will check the database for new bugs and unfixed bugs assign new bugs to programmers and ask the programmers to fix the unfixed bugs as early as possible. Bug track is a project management system and professional issue-tracking. It is secure, reliable, suitable and totally web-based. Bug track is multilingual. It has English, Swedish, German and Japanese user interfaces. Languages may be chosen for each user individually. More connections will be able to bring soon. All system fields provide Unicode to deal with any language user chooses.
Bug tracking is convenient, secure, reliable, multi-lingual and web-based system. It is a professional issue-tracking and project management system.
Bug tracking is very comfortable, not difficult to use and user friendly. The system is given a lot of attention and planned to make its user interface as convenient as possible and no process of learning is required; user may start using it directly.
Bug track is reliable as it has lightning-fast response and 99.9% uptime.
Bug track is protected as servers are situated in Equinox datacenter in Chicago - one of the most reliable and protected collection facilities in the world. The information is maintained very secure.
Bug tracking is completely web-based; it is available on online and there is nothing to install and any hardware or software to buy.
2.1 Bug Tracking:
Bugs are the unfortunate evil in software. This is not because developers are necessarily bad, or that programmers write a bad code, it's just that sometimes programmers cannot think of everything that could possibly happen when users are involved. Users are the main reason that programs might crash, not the code. To alleviate the complexity of error handling in an application the software debian bug tracking is the solution to plan, manage, track and coordinate the software's before their production to the ultimate client.
Bug tracking systemÂ is aÂ computer application planned to help user perform a particular task that is planned to helpÂ standard assuranceÂ andÂ programmersÂ keep path of reportedÂ software bugsÂ in their work. It may be considered as a type ofÂ issue tracking system.
Database is the major component of the bug tracking system that keeps the record facts. Facts means the time was bug reported versions, bug complexity or priority, the information of the bug and how to solve the bug. Clear and centralized overview of development requests is provided by bug tracking system, this is the main benefit.
2.2 Current systems:
In the present situation, the system follows the sequence of steps described below to develop software. First, when the project comes to the company, it is the responsibility of the project manager to assign the works to his team members. After the completion of the analysis, design and the coding phases the software is send to the tester. The tester is responsible for identifying bugs and reporting them to his project manager. He has to list out all the bugs in a paper and forward the report to his manager. Then the project manager sorts all the bugs according to their priorities and assigns the programmers to fix the bugs. The programmer fixes the bugs and gives report to the project manager.
1) Bugs are inevitable in development of any software.
2) Bugs happen at any stage of growth in any kind of product.
3) Proper maintenance and details of bugs has to take great care.
4) Bugs not only harm software but also affect the performance of software developing team.
2.2.1Disadvantages of Current system:
Effort and time consuming.
Every time the tester needs to represent the details of the bug on a paper. Moreover he needs to follow unnecessary formalities while representing the paper. When bugs are more in number, sorting them according to their priorities by referring the paper will be too hectic for the project manager. This may have an adverse effect on the project duration.
Chance of occurring human errors.
The tester may fail to represent all the bugs when they are more in number. The project manager may also fail to sort them properly according to their priorities when there are more bugs.
Lack of communication.
All the team members may not have proper communication with each other. Sometimes they may not have good relation with their project manager. All these situations may lead to development of an inefficient product.
Best quality may not be achieved.
With all the above mentioned disadvantages the quality of the product may not be good.
1. Bugs are not properly maintained.
2. It is not easy to track the bug if the bug is over looked.
3. The effort spent and the cost of the project may not be worthy.
4. The whole database must be searched for a special bug which might have happened sometime before.
5. Existing system is time consuming and error prone.
6. Customer satisfaction is not guaranteed.
2.3 Proposed system:
The proposed system is designed by using the problem statement. This system eliminates the problems in existing system. The requirements of the proposed system can be defined by going through the existing system and its problems. The proposed system should be:
1) Interactive and quicker accesses with less time access.
2) Error free that is less of human errors.
3) Secure and best quality must be achieved.
4) Easy to use by everyone.
5) Low cost.
6) Improving customer satisfaction and good communication must be provided.
2.3.1 Advantages of proposed system:
ïƒ The proposed system provides the product, bugs and bug tracking.
ïƒ This system keeps all the information from bug origin to bug resolution. The bug history is maintained in the proposed system.
ïƒ Each and every product has versions, which are stored in database for easy maintenance.
ïƒ In proposed system the search is based on status, priority and operating system it mean this product provides efficient search techniques.
ïƒ The proposed system provides fully authenticated system with username and password encryption.
ïƒ One can keep track of a bug in a product with lower cost and effort.
2.4 Bug Tracking Software:
Bug tracking software is a Defect Tracking System or a set of scripts, which provides and maintains a database of problem reports. Bug tracking software allows individuals or groups of developers to keep track of unfixed bugs in their product effectively. Bug tracking software can track bugs and code changes, share information with teammates, submit and review patches, and providing standard assurance.
Bug Tracking Software Benefits:
Depending on development requirement and the bug tracking software, one can expect to get benefits from bug tracking software. Some of the benefits are:
Improve communications between groups of people
The standard of the software must be increased
Improve customer satisfaction with bug free software
Provides a form of accountability
Increases overall productivity
Above are benefits that one may achieve from implementing bug tracking software in an environment? There are many bug tracking software packages available, it is always a good idea to make sure that one can determine their bug tracking requirements before you choose your bug tracking software solution.
2.5Bug Tracking Software for Windows
By tracking bugs, the bug tracking software helps to manage the developing projects more effectively. In this software one can know how many bugs are processed, how many bugs are pending and how many bugs are closed which will bring better response to the user. This software allows simultaneous access to and by different users and it records the bug reports in the database. It offers auto login, attachments, bug versions, sorting, date etc.
Guidelines for effective bug tracking:
The bug reports contains hours, may be days of the activity. It is necessary to the firm's data, which should be well organized and protected. The backup must be maintained and recorded in database daily.
1. Make a build of the software daily
In an environment bug tracking works well is there is a daily build. This enables testers to test the most recent version of software so that they are not reporting bugs which are already fixed. They also discover newly introduced bugs fast while the code is still fresh in the memory of the developers that introduced them.
Use build numbers
When applicable, build numbers should be used to specify what version of software a bug was found in, what version it was fixed in, and what version a fix was verified in. Revision numbers of source code modules modified to fix bugs are helpful notes for developers, but they aren't necessary to coordinate work between test and development.
Use a process to handle bug reports
Bug reports should go through a process that ensures that they aren't closed if they shouldn't be. Such a process should require that the person who reported the bug be the one to verify that it has been fixed or to approve any other type of resolution. The typical bug report life cycle would include the following status values: New, Assigned, Resolved, Verified and Closed, respectively.
Use a resolution field
To keep the bug report life cycle simple, use a resolution field to specify how problems are resolved <http://www.prtracker.com/Resolving-Bug-Reports.html>. Possible resolutions include: Fixed, Won't Fix, Not Reproducible, Duplicate, By Design and External.
Do not triage bug reports in meetings
Avoid using a committee or meeting to triage bug reports. This will use a lot of man-hours that could be used fixing bugs. If the schedule dictates a triage, don't close bug reports in the meeting because this will circumvent the quality process by sidestepping testers that report bugs. Instead, use the bug triage to reprioritize, postpone, or resolve as won't fix.
Handle feature requests separately
Feature requests and specifications are often recorded as bug reports. These should be recorded separately so that they can be triaged, and so that they don't skew statistics for measuring software quality.
Describe how to reproduce bugs
A bug report should include a step-by-step description on how to reproduce the bug. This reduces the amount of time developers spend trying to reproduce the bug before they fix it. Finding the minimal steps to reproduce the bug will save even more developer time.
Keep bug reporting simple
Don't make bug reporting complicated by requiring entry of more data than is really necessary. If it's too much work to enter bugs into the tracking system, some bugs won't be entered, or people may start going around the system and begin reporting bugs by email or word-of-mouth.
Record how bugs are detected
Keeping records on how bugs are detected helps you determine how best to spend your testing dollars. Suggested choices for a detection method field include: Interactive Testing, Test Script Execution, Test Script Design, Unit Testing, Integration Testing, Code Review, Beta Testing and Customer Report.
Kernel of operating system is Linux. Many other applications around are needed. Distribution is the collections of software around the Linux kernel. Firms that increase such distributions are called distributors; doing support and training distributors earn money by selling their supplying in boxes.
The Debian Project is a group of singles who have made usual reason to establish a free operating system. So operating system that was created is called Debian GNU/Linux, or Debian. Task is in movement to improve for other to supply Debian, containing in particular the Hurd , NetBSD and FreeBSD, have even been talking of a possible port to Windows. These singles, called Debian developers, are joined with the internet of trust built by cross-signing GPG keys.
Computer operating system is the form of open and free source software is Debian. The first compose debian gui/linux is famous and influential Linux operating system. Debian is shared with many of software packages which are available on web and ready to use directly. There is no need to buy the debian software packages. They are available free and open with license. Debian is used as a server operating system as well as desktop system.
Debian is different from other distributions because:
1. Debian is not a firm but an organization.
2. Debian does not sell anything.
3. Debian members (maintainers) are volunteers.
4. The common goal working of maintainers is to build the best operating system in low cost.
5. Free software's are available on internet which can be installed directly.
6. Debian can be getting by buying it from distributor on CD and by downloading it on online.
3. System Analysis and Requirements:
In the analysis phase, each and every project is to be designed and checked for its feasibility. Feasibility is nothing but how efficient the system with stands the risks and circumstances that arises during the implementation phase. All the projects are feasible when many resources and infinite time. This is not possible in practical world. Therefore Feasibility study is necessary. Feasibility studies the sort of simulation of future development process is worthwhile or not.
3.2 Feasibility study:
1. Economic feasibility
2. Legal feasibility
3. Time feasibility
4. Technical feasibility
5. Resource feasibility
3.2.1 Economic feasibility:
The development of this system does not required investing money of it. So what is available is used. What is available is also used because the system does not intend for commercial are within the present scope form, economic feasibility is not warranted for this system.
3.2.2 Legal Feasibility:
Legal feasibility is a determination of any violation or liability that could result from the development of the system. The system is not intended for commercial use within the present scope warranted for the system.
3.2.3 Time feasibility:
This is a live project so there is matter of dead line for completion of the project. Hence the time feasibility is warranted in this project.
3.2.4 Technical feasibility:
Technical feasibility is associated with it as there is already developed dataflow machine. Hence there is no need for new technology that has to be developed.
3.2.5 Resource feasibility:
This debian bug tracking system has no need of bulk or more resources. It just requires the development center that has personal computer equipped with hardware and software required to build the system.
3.3 System Requirement Specification (SRS) :
The introduction of an SRS identifies the purpose, scope, definitions, acronyms, abbreviations, references and overview of the requirements of the documents.
A perfect answer to track the bugs of a product, solution or an application is Debian bug tracking system (DBTS). DBTS gives permissions to single or group of developers to keep track of unfixed bugs in their product effectively which is also called as Defect Tracking System.
The purpose of software requirements specification specifies the intention and the intended audience of the S.R.S.
The DBTS aims to developing a fully atomize system for tracking the following objects in any software solution centre, such as products, product versions, users (programmers) in the product, system configuration and product hierarchy. These all items have to be tracked before the product resealed for production.
The scope of S.R.S identifies the software product to be produced. The capabilities, objectives and applications etc.,
The project has implementation in any software development centre where there will be numerous solutions as well as enormous technologies to develop these solutions which require man power. The system is generic and global which can be delivered to any client where this architecture is acceptable. However the system falls in middle term category i.e it is going to last for five years, then the system can be expanded with less or no change in the underline architecture and source.
This section provides the road map for the SRS. The other parts of the SRS contain the product functions, the constraints on the system which includes any assumptions and dependencies.
The SRS also contains the details of process and data requirements.
The DBTS can increase a lot the productivity and accountability of single employees by giving a documented workflow and positive feedback for good performance.
3.5 Overall Description
The main functions associated with this project are described in this section of the SRS. The characteristics of a user for this project are indicated. The assumptions, constraints, and dependencies described in this section result from interaction with project designer.
3.6 Apportioning of Requirements
More advanced versions of DBTS called Wireless BTS, not a part of this project, will be incorporated into the wireless data entry in upcoming versions 2.0 - 2005, in the confinement of the company through decks and cards embedded in each and every employee's wireless devices.
3.7 Specific Requirements
This section of the SRS provides a description of the observable of a software system. It also includes a description of the entire system
3.7.1 Interface Requirements
The interface for the DBTS system requires a combination of interactive .net computing software and MS Internet Explorer web browsers, as well the availability of workstations connected to the intranet central server for distributed and scalable distribution of data to the clients.
The user interface for this system will be an MS capable web browser. However the system could be best viewed in any third party web browser.
A workstation client connected to the central serve intranet with addition of mouse and mouse pack as well keyboard.
MS capable browsers with access to the intranet server, the MS developers network and MS Developers Kit from MS or visual studio IDE 7.0,7.1, 7.2 and a text editor for preparing HTML files.
The communication interface here is intranet access from server to clients in workstations.
4. Modules & Description
The Bug Tracking System first activates the login form. Here the user enters the User name and password and our system starts the authentication process in which the username and password are matched with the existing username and password in the database. If the password matches then it is allowed to the main page else it warns the user for Invalid User name and password.
After successful authentication the system activates menus. The activity log also prepared for failures and security.
List Of Products
After successful authentication the user is provided with the list existing products. Here the user can view the details of products and can modify the existing products. This project even provides the facility of adding new projects.
All the products are maintained in several versions. As it is not possible to complete the whole project in a single version Features required for the product are categorized into several version with deadlines. And the versions are completed according to their dead line dates. Here the user can add new versions to a product or can modify the existing details of version.
In order to complete the project each product is allotted with Resources or users. First all the employees with their names and qualifications are stored in the database. Each user is allotted to the product based on their rating, Qualification and designation. For each user Effective date is stored which specifies the total period a user is valid for that product.
In this module the user is provided with the facility for adding bugs or updating the existing bugs. As the number of bugs for a product can be very large this system is provided with efficient filtering. The user can filter the bugs based on the priority, database, operating system and status. After the user applies filter the list of bugs are displayed from the database.
Here the bug history is maintained. All the solutions given for the bug resolution by various users are stored. As the bug needs several techniques or methods for resolution it is important to store the history of the bug.
This displays the list of users for whom the bug is assigned for resolution. As the bug need to be resolved for completing the product several user are assigned to find a solution for the bug. The user can add this bug to a new user or he can modify the existing user details.
This gives a list of attachments for a particular bug. The bug can be of any type it can be a database bug or a GUI bug. So while you add a bug you need to provide with the details of bug. So the file attachments can be a document, database file or an image file. All then attachments are stored in a location along with the size and type of the file. Here the user can add a new attachment or can change the details of existing files.
All the bugs saved in the database will have a particular hierarchy. There might be bugs which can be related to the earlier bugs saved in the database so our system is provided with a hierarchy. And user can add child nodes in this hierarchy or he can modify the existing values of the nodes. This hierarchy is based on the parent child relationship between the bugs.
This displays a list of all solutions provided by the users allotted to a bug. This stores the action type and the necessary resolution provided by the user.
This displays list of resources allotted to the project. As the bugs need to be resolved resources are provided for the bugs. These Resources will be the resources allotted to the project. The resources are allotted based on the rating of the employee.
Product Bug Hierarchy
This module is just for displaying the hierarchy for the easy Look of the bugs. Here the bugs are displayed in the form of parent child nodes, as it is difficult for the user to look at the vast number of bugs in the database. And one cannot easily access the relation between the bugs.
Product User Hierarchy
This module if for displaying the users allotted to the bug. The users along with their name and designation are displayed in this module. Even in the allotment of resources there can be hierarchy between the employees depending on their designation. So this module simplifies the hierarchy among the employees.
Our system provides with the feature of advanced search technique. Generally Number of bugs for a project increased tremendously so if we want to know about a particular bug It takes much amount of time. With the search screen provided one can filter the bug's base on priority, product, severity, database and type of operating system. He can also list the bugs between particular time based on the start date and end date. After Searching it displays a list of bugs. From this list the user can modify the existing bugs or can add a new bug.
All the users of this system are displayed in this module. One can add new user or can update the details of an existing user. Here the password provided by the user is encrypted before saving them to the database for proper security. This module saves the details like address, phone and email.
All the Values that we are using in this system are configurable. Values like status, priority and others can be added dynamically on the screen. Suppose if we limit these fields by hot coding them and if the user wants to add a new value again he has to come to the developer of the product. So In order to avoid this it is provided with the feature of adding values from the screen. And the user can change the status to In Active whenever he wants.
In order for the efficient Tracking of the system logs are maintained. As the logs will be in vast it will be a problem for user for checking the database. The Log View module can be searched based on the user and Records between a start date and end date.
In this once the user clicks on Log out First the session variable is killed and then the system is redirected to the login page.
At all the stages, whenever user performs an operation by clicking a button, automatically the Bug Tracking System logs the activity.
4.11 System Environment
4.11.1 Hardware Specifications:
The bug tracking system is developed on the following specifications of hardware.
Application Server Configuration
Pentium 4 or later versions
40GB or more
256MB or more
32 bit PCI
Database Server Configuration
Pentium 4 or later versions
40GB or more
256MB or more
32 bit PCI
Fire wall protected
Client System Configuration
Pentium 4 or later versions
40GB or more
256 MB or more
4.11.2 Software Specifications:
The bug tracking system is developed on the configuration of following software:
Application Server Configuration
Windows 2000 Server or later versions
Java / MS.Net
Database Server Configuration
Win2000 server or later versions
SQL Server 2000
5. CURRENT TECHNOLOGIES:
Introduction to Java:
Java language was first called as OKA but later in 1995 it is named as JAVA. When the java was originally invented was not for internet but the main importance was to invent a platform independent language (which can work under any architecture) which can be used to create new software to be joined in different consumer electronic systems. Java was invented at sun Microsystems in 1991 by Mike Sheridan, Chirs Warth, James Gosling, Ed Frank and Patrick Naughton. The first working version took 18 months to develop.
C is a structured language which is easy to learn and it was powerful and efficient. C is a programmer's language and designed for programmers. C was very successful and helpful language. But the complexity of programs was increased, C++ is needed. C and C++ languages are designed only for a particular target. This was the problem with C and C++. C++ can compile any type of CPU. To compile any type of CPU it requires a full compiler targeted for a particular CPU. The cost is very high for compilers and time taken a lot to creating. There was a need to fine the solution for easy, cost efficient and less time consuming language. Then, the programmers started working on a portable and platform independent which can give a code and run on any CPU in different environments. This was the first reason for creation of java.
World Wide Web (WWW) is been know by everyone, Java came in to the picture because WWW need portable and platform independent programs. The web contains operating systems, central processing units, many types of systems. Users like to run all the programs from different types of platforms which are attached to web. The computer language design because the web, too, demanded portable programs. What was once an irritating but low priority problem had become a high profile necessity. While the desire for an architecture neutral programming language provided the initial spark, the Internet ultimately led to Java's large scale success. World Wide Web was the second reason for java creation.
Java has most of its character and shares attributes that helped from C++ and C successful.
Introduction to Java data base connectivity (JDBC)
Open Data Base Connectivity (ODBC): For C-based interface to SQL-based database engines, ODBC gives a consistent interface for interacting with a database and for accessing database information about the database system vendor , how the data is stored, where the data is located and etc is meta data. Single vendors give specific drivers or "bridges" to their specific database management system. ODBC and SQL can be connected to a database and make changes it in a very organized method. ODBC began as a PC standard, it has become nearly an industry standard.
Though SQL is well suited for manipulating databases, it is unsuitable as a general application language and programmers use it primarily as a means of communicating with databases--another language is needed to feed SQL statements to a database and process results for visual display or report generation. Unfortunately, you cannot easily write a program that will run on multiple platforms even though the database connectivity standardization issue has been largely resolved. For example, if you wrote a database client in C++, you would have to totally rewrite the client for each platform; that is to say, your PC version would not run on a Macintosh. There are two reasons for this. First, C++ as a language is not portable for the simple reason that C++ is not completely specified, for example, how many bits does an int hold? Second and more importantly, support libraries such as network access and GUI libraries are different on each platform. Enter Java.
You can run a Java program on any Java-enabled platform without even recompiling that program. The Java language is completely specified and, by definition, a Java-enabled platform must support a known core of libraries. One such library is JDBC, which you can think have as a Java version of ODBC, and is itself a growing standard. Database vendors are already busy creating bridges from the JDBC API to their particular systems. JavaSoft has also provided a bridge driver that translates JDBC to ODBC, allowing you to communicate with legacy databases that have no idea that Java exists. Using Java in conjunction with JDBC provides a truly portable solution to writing database applications.
The fundamental issues encountered when writing any database application are:
Creating a database. You can either create the database outside of Java, via tools supplied by the database vendor, or via SQL statements fed to the database from a Java program.
Connecting to an ODBC data source. An ODBC data source is a database that is registered with the ODBC driver. In Java you can use either the JDBC to ODBC Bridge, or JDBC and a vendor-specific bridge to connect to the datasource.
Inserting information into a database. Again, you can either enter data outside of Java, using database-specific tools, or with SQL statements sent by a Java program.
Selectively retrieving information. You use SQL commands from Java to get results and then use Java to display or manipulate that data.
To enter the data into the database, create a Java application that follows these steps:
Load the JDBC-ODBC Bridge. You must load a driver that tells the JDBC classes how to talk to a data source. In this case, you will need the class JdbcOdbcDriver:
Connect to a data source. A URL is used to connect to a particular JDBC data source. Given that you have loaded the JDBC-ODBC bridge driver, URLs should be in the following form jdbc:odbc:data-source-name.
Send SQL statements to create the table. After you have created the table, you can the insert the appropriate values
Connecting a Java program to a database
Currently, there are two choices for connecting your Java program to a data source. First, you can obtain a JDBC driver from your database vendor that acts as a bridge from JDBC to their database connection interface. Second, JavaSoft provides a JDBC-ODBC bridge called class JdbcOdbcDriver and, hence, you can connect to any ODBC data source.
Once you have established a JDBC database link, open a connection to that data source through a Connection object.
Talking to a Database
Given a connection to a database, you can send SQL statements to manipulate that database. Using the Connection.createStatement method, obtain a Statement object and then execute method executeQuery or executeUpdate. JDBC does not put any restrictions on the SQL you send via the execute methods. but you must ensure that the data source you are connecting to supports whatever SQL you are using. To be JDBC-compliant, however, the data source must support at least SQL-2 Entry Level capabilities.
When performing the same operation multiple times, use a Prepared Statement for runtime efficiency, which is precompiled by the SQL engine (assuming your data source supports this feature). Prepared statements are also useful when you have lots of arguments to specify for a particular SQL command.
Prepared Statement is an extension of Statement and, consequently, behaves like a Statement except that you create them with the method.
You can access information about the database as a whole, or about a particular query ResultSet. This section describes how DatabaseMetaData and ResultSetMetaData objects are obtained and queried.
A transaction is a set of statements that have been executed and committed or rolled back. To commit a transaction, call the method commit on the appropriate connection; use the rollback to remove all changes since the last commit. By default, all new connections are in auto-commit mode, which means that each "execute" is a complete transaction.
A stored procedure is a block of SQL code stored in the database and executed on the server. The CallableStatement interface allows you to interact with them. Working with CallableStatement objects is very similar to working with PreparedStatements. The procedures have parameters and can return either ResultSets or an update count. Their parameters can be either input or output parameters. Input parameters are set via the setXXX methods. Output parameters need to be registered via the CallableStatement.registerOutParamter method. Stored procedures need to be supported by the database in order to use them. You can ask the DatabaseMetaData if it supports it via the method supportsStoredProcedures.
JDBC Exception Types
JDBC provides three types of exceptions:
The SQLException is the basis of all JDBC exceptions. It consists of three pieces of information, a String message, like all children of Exception, another String containing the XOPEN SQL state (as described by specification), and a driver/source specific int for an additional error code.
In addition, multiple SQLException instances can be chained together.
The SQLWarning class is similar to SQLException, however it is considered a noncritical error and is not thrown. It is up to the programmer to poll for SQLWarning messages through the getWarnings methods of Connection, ResultSet, and Statement. If you do not poll for them, you will never receive them. Also, the next time something is done with a Connection, ResultSet, or Statement, the previous warnings are cleared out.
The DataTruncation class is a special type of SQLWarning. It is reported with other SQLWarning instances and indicates when information is lost during a read or writes operation. To detect a truncation, it is necessary to perform an instanceof DataTruncation check on each SQLWarning from a getWarnings chain.
Introduction to Java server pages
While there are numerous technologies for building web applications that serves dynamic content, the one of that has really caught the attention of the development community is JSP. And not without ample reason either. JSP not only enjoys cross platform and cross web server support, but effectively melds the power of server side java technology with the WYSIWYG features of static HTML pages.
JSP pages typically comprise of:
Static HTML/XML components
Special JSP tags
Optionally, script lets of code written in the Java programming language called "scrip lets".
Consequently, we can create and maintain JSP pages by conventional HTML/XML tools.
It is important to note that the JSP specification is a standard extension defined on top of the servlet API. Thus, it leverages all of your experience with servlets.
There are significant differences between JSP and servlet technology. Unlike servlets, which is a programmatic technology requiring significant developer expertise, JSP appeals to a much wider audience. It can be used not only by developers, but also by page designers, who can now play a more direct role in the development life cycle.
Another advantage of JSP is the inherrent separation of presentation from content facilitated by the technology, due its reliance upon reusable component technologies like the Java Bean component architecture and Enterprise Java Bean technology.
Separation of static from dynamic content: With servlets, the logic for generation of dynamic content is an intrinsic part of the servlet itself, and is closely tied to the static presentation templates responsible for the user interface. Thus, even minor changes made to the UI typically result in the recompilation of the servlet. This tight coupling of presentation and content results in brittle, inflexible application. However, with JSP the logic to generate the dynamic content is kept separate from the static presentation template by encapsulating it within external Java Bean component. These are then created and used by the JSP page using special tags and scriptlets. When a pagedesigner makes any changes to the presentation template, the JSP page is automatically recompiled and reloaded into the webserver by the JSP engine.
Write once run anywhere: JSP technology brings the "Write Once, Run Anywhere" paradigm to interactive web pages. JSP pages can be moved easily across platforms and across web server, without any changes.
Dynamic content can be served in a variety of formats: There is nothing that mandates the static template data within a JSP page to be of a certain format. Consequently, JSP can service a diverse clientele ranging from conventional browsers using HTML/DHTML, to handle wireless devices like mobile phones and PDAs using WML, to other B2B applications using XML.
Comparing JSP with ASP (active server pages)
Web Server Support
Most popular web servers including apache, Netscape and Microsoft IIS can be easily enabled with JSP.
Native support only within Microsoft IIS or personnel web server. Support for select servers using third party products.
Platform independent. Runs on all java enabled platforms.
Is fully supported under windows. Deployment on other platforms is cumbersome due to reliance on the win32 based component model.
Relies on reusable, cross platform components like java beans, EJB, and custom tag libraries.
Uses the win32 based COM component model.
Can use the java programming language or java script.
Supports Vbscript and Jscript for scripting.
Works with the java security model.
Can work with windowsNT security architecture.
Uses JDBC for data access.
Uses ADO for data access.
JSP is extensible with custom tag libraries.
Cannot use custom tag libraries and is not extensible.
6. SYSTEM DESIGN
Bug Tracking E-R diagram
DATA FLOW DIAGRAMS
November 8, 2006 java complete reference seventh edition