V-CHECK (ONLINE

R.T.O)

Sr.No. Title Page No.

1. Introduction
2. Review of literature
3. Planning

4. Coding

5. Testing

6. Output

7. User module

8. Costing

9. Future implementation

10. Conclusion

11. Bibliography

1
 V-CHECK (ONLINE
R.T.O)

INTRODUCTION

2
 V-CHECK (ONLINE
R.T.O)

REVIEW OF
LITERATURE

3
 V-CHECK (ONLINE
R.T.O)

PLANNING

4
 V-CHECK (ONLINE
R.T.O)

5
 V-CHECK (ONLINE
R.T.O)

6
 V-CHECK (ONLINE
R.T.O)

7
 V-CHECK (ONLINE
R.T.O)

8
 V-CHECK (ONLINE
R.T.O)

9
 V-CHECK (ONLINE
R.T.O)

10
 V-CHECK (ONLINE
R.T.O)

11
 V-CHECK (ONLINE
R.T.O)

12
 V-CHECK (ONLINE
R.T.O)

13
 V-CHECK (ONLINE
R.T.O)

14
 V-CHECK (ONLINE
R.T.O)

15
 V-CHECK (ONLINE
R.T.O)

16
 V-CHECK (ONLINE
R.T.O)

17
 V-CHECK (ONLINE
R.T.O)

18
 V-CHECK (ONLINE
R.T.O)

19
 V-CHECK (ONLINE
R.T.O)

CODING

20
 V-CHECK (ONLINE
R.T.O)

TESTING

21
 V-CHECK (ONLINE
R.T.O)

OUTPUT

22
 V-CHECK (ONLINE
R.T.O)

USER MODULE

23
 V-CHECK (ONLINE
R.T.O)

COSTING

24
 V-CHECK (ONLINE
R.T.O)

FUTURE
IMPLEMENTATION

25
 V-CHECK (ONLINE
R.T.O)

CONCLUSION

26
 V-CHECK (ONLINE
R.T.O)

BIBLIOGRAPHY

27
 V-CHECK (ONLINE
R.T.O)

The Powerful New Features of Microsoft Access 2007

For as long as businesses and individuals have used data, there has been a need for a way to collect, maintain
and use that data. Database programs like Microsoft Access were built with that need in mind, and with
every new generation of the Access program, Microsoft has attempted to make the database experience
safer, easier and more users friendly. That tradition continues with the release of the new Access 2007, part
of the Microsoft Office 2007 family of products.

Prebuilt Solutions

One of the most powerful new features of the Microsoft Access 2007 program is the introduction of a
number of prebuilt solutions. These prebuilt solutions are a part of the Getting Started screen, making it
faster and easier than ever to get started right out of the box.

These prebuilt solutions can be used for such things as tracking contracts, issues, events, tasks, assets and
much more. The prebuilt solutions provided can then be used as templates as is, or they can easily be
enhanced and customized to accommodate virtually any kind of information needed. These templates allow
information to be used however it is needed.

In addition to the power of the prebuilt solutions, Access 2007 also provides a fresh new look and feel with a
new results oriented user interface. This new interface makes it easier than ever for users to create, modify
and enhance applications. The new interface is context sensitive and efficient. Containing nearly 1,000
available commands, the user interface is designed to display only those which are relevant to the task at
hand. The new user interface also features a tabbed window view and a new status bar, along with a modern
looking title bar and scroll bars for easier navigation.

Speaking of navigation, Access 2007 also features a new navigation pane which provides a comprehensive
and user friendly view of the various tables, forms, queries and reports that make up the database. Access
2007 also provides the ability to create custom groups, allowing users to organize all their forms and reports
into a single table.

The creation of tables is also simplified and enhanced within Access 2007, making it easier for users without
prior database experience to create dynamic and useful tables. The information can be entered directly into
the table, just like within Excel. As each new value is entered, Access 2007 automatically adds a new field

28
 V-CHECK (ONLINE
R.T.O)

and detects the type of data it contains. Access 2007 even provides the ability to paste an entire Excel
spreadsheet into Access, with no need to retype data.

The new Access 2007 also provides users with the ability to quickly and easily import contact records
directly from Microsoft Office Outlook 2007. An Outlook contact record can easily be imported into Access
2007, and records can be exported from Access 2007 to Outlook as well.

The ability to quickly and easily share information between different programs is one of the most powerful
features of the new Access 2007. This ability makes it easy to collaborate with colleagues, gather
information, avoid the need for time-consuming retyping and ensure that the data needed is always at hand.
Users of the new Access 2007 will find many improvements in the new product, and it is a good idea for
those currently using older products to learn as much as possible about the new features and benefits of this
powerful database program

Development

All database tables, queries, forms, reports, macros, and modules are stored in the Access Jet database as a
single file.

For query development, Access offers a Query Designer, a graphical user interface that allows users to
create queries without knowledge of the SQL programming language. In the Query Designer, users can
"show" the data sources of the query (which can be tables or queries) and select the fields they want returned
by clicking and dragging them into the grid. Joins can be created by clicking and dragging fields in tables to
fields in other tables. Access allows users to view and manipulate the SQL code if desired. Any Access
table, including linked tables from different data sources, can be used in a query.

Access also supports the creation of Pass-Through queries. These are queries that can be linked to external
data sources through the use of ODBC connections on the local machine. This enables users to interact with
data stored outside the Access programme without using linked Tables. The Pass-Through queries are
written using the SQL syntax supported by the external data source.

When developing Reports that are linked to Queries placing or moving items in the design view of the
Report, Access runs the linked query in the background on any placement or movement of an item in that
Report. If the Report is linked to a Query that takes a long time to return records this forces you to wait until
the query has run before you can add/edit or move the next item in the Report (this feature cannot be turned
off).

Non-programmers can use the macro feature to automate simple tasks through a series of drop down
selections. Macros allow users to easily chain commands together such as running queries, importing or

29
 V-CHECK (ONLINE
R.T.O)

exporting data, opening and closing forms, previewing and printing reports, etc. Macros support basic logic
(IF conditions) and the ability to call other macros. Macros can also contain sub-macros which are similar to
subroutines. In Access 2007, macros are significantly enhanced with the inclusion of error handling and
temporary variable support. Access 2007 also introduces embedded macros that are essentially properties of
an object's event. This eliminates the need to store macros as individual objects. Macros however, are
limited in their functionality by a lack of programming loops and advanced coding logic. Most professional
Access developers use the VBA programming language for a richer and more powerful development
environment.

The programming language available in Access is, as in other products of the Microsoft Office suite,
Microsoft Visual Basic for Applications, which is nearly identical to Visual Basic 6.0 (VB6). VBA code can
be stored in modules and code behind forms and reports. Modules can also be classes.

To manipulate data in tables and queries in VBA, two database access libraries of COM components are
provided: the Data Access Objects (DAO), which is included in Access and Windows and evolved to ACE
in Microsoft Access 2007 for the ACCDE database format, and ActiveX Data Objects ActiveX Data Objects
(ADO). Beside DAO and ADO, developers can also use OLE DB and ODBC for developing native C/C++
programs for Access. For ADPs and the direct manipulation of SQL Server data, ADO is required. DAO is
most appropriate for managing data in Access/Jet databases, and the only way to manipulate the complex
field types in ACCDB tables.

In the database container or navigation pane of Access 2007, Access automatically categorizes each object
by type. Many Access developers use the Leszynski naming convention, though this is not universal; it is a
programming convention, not a DBMS-enforced rule. It is particularly helpful in VBA where references to
object names may not indicate its data type (e.g. tbl for tables, qry for queries).

Microsoft Access is most often used for individual and workgroup projects (the Access 97 speed
characterization was done for 32 users). Since Access 97, and with Access 2003 and 2007, Microsoft Access
and hardware have evolved significantly. Databases less than 1 GB in size (which can now fit entirely in
RAM) and 50 simultaneous users are well within the capabilities of Microsoft Access. Of course,
performance depends on the database design and tasks. Disk intensive work such as complex searching and
querying are the most time consuming.

As data from a Microsoft Access database can be cached in RAM, processing speed may be substantially
better when there is only a single user or if the data is not changing. In the past, the effect of packet latency
on the record locking system caused Access databases to be too slow on Virtual Private Network (VPN) or
Wide Area Network (WAN) against a Jet database. This is less of an issue now with broadband connections.
Performance can also be enhanced if a continuous connection is maintained to the back end database
throughout the session rather than opening and closing it for each table access. If Access Database

30
 V-CHECK (ONLINE
R.T.O)

performance over VPN or WAN suffers, then Microsoft Terminal Services is an effective solution. Access
databases linked to SQL Server or Access Data Projects work great over VPN and WAN.

Split Database Architecture

Microsoft Access applications can adopt split database architecture. The database can be divided into a front
end database that contains the application objects (queries, forms, reports, macros, and modules), and is
linked to tables stored in a back end shared database containing the data. The 'back-end' database can be
stored in a location shared by many users, such as a file server. The 'front-end' database is distributed to each
user's desktop and linked to the shared database. Using this design, each user has a copy of Microsoft Access
installed on their machine along with their application database. This reduces network traffic since the
application is not retrieved for each use, and allows the front end database to contain tables with data that is
private to each user for storing settings or temporary data. This split database design also allows
development of the application independent of the data. When a new version is ready, the front end database
is replaced without impacting the data database. Microsoft Access has two built-in utilities, Database Splitter
and Linked Table Manager, to facilitate this architecture.

Linked tables in Access use absolute paths rather than relative paths, so the development environment either
has to have the same path as the production environment or a "dynamic-linker" routine can be written in
VBA.

This is not an economical setup across slow networks, or large organizations separated by great distances, as
this will result in excessive lag to database users. SQL backend should be considered in these circumstances.

Access to SQL Server Upsizing (SQL as a backend)

To scale Access applications to enterprise or web solutions, a recommended technique is to migrate to

Microsoft SQL Server or equivalent server database. A client-server design significantly reduces
maintenance and increases security, availability, stability, and transaction logging.

Access includes an Upsizing Wizard that allows users to upsize their databases to Microsoft SQL Server an
ODBC client-server database. An additional solution, the SQL Server Migration Assistant for Access
(SSMA), is also available for download from Microsoft.

A variety of upsizing options are available. After migrating the data and queries to SQL Server, the
MDB/ACCDB Access database can be linked to the database. This is the easiest migration and most
appropriate if the user does not have rights to create objects such as stored procedures on SQL Server.

31
 V-CHECK (ONLINE
R.T.O)

Retrieving data from linked tables is optimized to just the records needed, but are not as efficient for multi-
table joins that may require copying the whole table across the network.

Access databases can also be converted to an Access Data Projects (ADP) which is tied directly to one SQL
Server database. ADPs support the ability to directly create and modify SQL Server objects such as tables,
views, stored procedures, views, and SQL Server constraints. The views and stored procedures can
significantly reduce the network traffic for multi-table joins. Unfortunately, ADPs do not support temporary
tables or link to other data sources beyond the single SQL Server database. (MDB/ACCDB databases can
link to a variety of data sources and let you perform heterogeneous queries across them).

Finally, some Access databases are completely replaced by another solution such as ASP.NET or Java once
the data is converted.

In many cases, hybrid solutions are created where web interfaces are built by developers using ASP.NET,
while administrative or reporting features that don't need to be distributed to everyone and/or change often,
are kept in Access for information workers to maintain.

While all Access data can migrate to SQL Server, it should be noted that Access queries are richer than SQL
Server queries, so some queries cannot migrate successfully. In some situations, you may need to translate
VBA functions and user defined functions into TSQL or .NET functions / procedures. Crosstab queries can
be migrated to SQL Server using the PIVOT command.

Microsoft Access has a reputation among IT professionals as not being as economical on server resources
when running large query transactions, especially if users force-terminate the application on the client side.
Transactions that were running might still be running on the SQL server unbeknownst to the end user.

Security Features in MS Access

As a workgroup administrator, you might initiate or oversee workgroup-wide security practices for
protecting Access database applications. This section describes the options available in Access for protecting
databases and applications developed in Access. These options are independent of any additional security
measures at the operating system level.

Access supports several levels and methods of file protection:

• User access restriction

32
 V-CHECK (ONLINE
R.T.O)

You can use startup options to restrict access to default menus and toolbars, the Database window,
and special keys.

• File open protection

You can set a password to control opening the database.

• Source code protection

You can save an application as an MDE file to remove Microsoft Visual Basic for Applications
source code and prevent changes to the design of forms, reports, and modules.

• Database encryption

You can use database encryption to prevent unauthorized users from viewing the objects in an
application with a disk editor or other utility program. You can use encryption in conjunction with all
other methods of protecting an application.

• User-level security

You can use user-level security to apply the most powerful and flexible method of protecting an
application. However, establishing user-level security is a complex process that may exceed your
requirements. If this is the case, use one or more of the other security methods.

The strategy you use depends on the extent of security you need and how the application is used. The
following sections explain these options.

XML
1. Clean Semantics

Any query language for XML must be able to express simple queries simply. A good XML query language
should be usable by novice web-users, not just database experts. They will use the XML query language

33
 V-CHECK (ONLINE
R.T.O)

primarily for filtering and restructuring XML data, so these queries should be easy to express. More
complex queries involving say, aggregation or universal quantification, should be expressible as well but
may involve more complexity.

One possibility for a clean semantics is to base the query language upon the SQL select-from-where
statement.

SELECT expr
FROM path
WHERE cond

The semantics of such a statement can be interpreted as "for each path path found in the XML data where
condition cond holds on the path, produce an element in the query result defined by expr. If multiple paths
were contained in the FROM clause, the semantics would change to "for each combination of paths path1 ..
pathN found in the XML data..." similar to multiple table references in SQL. For example, the following
query selects employee names and phone numbers from an XML document.

Example Source document

<employees>
<emp>
<name>John Taylor</name>
<age>34</age>
<phone type=home>555-1234</phone>
<address>
<street>123 N. Main</street>
<city>Chicago</city>
<state>IL</state>
</address>
</emp>
<emp>
<name>Sue Smith</name>
<age>31</age>
<phone type=home>555-9999</phone>
<phone type=fax>555-8887</phone>
<address>
<street>100 W. State</street>
<city>Salt Lake City</city>
<state>UT</state>
</address>

34
 V-CHECK (ONLINE
R.T.O)

</emp>
</employees>

Query
SELECT <newemp> e.name e.phone </newemp>
FROM employees.emp e

Query Result
<newemp>
<name>John Taylor</name>
<phone type=home>555-1234</phone>
</newemp>
<newemp>
<name>Sue Smith</name>
<phone type=home>555-9999</phone>
<phone type=fax>555-8887</fax>
</newemp>

2. Path Expressions

Since XML elements often contain child elements, the query language should support "path expressions,"
which allow the writer easy access to nested elements. For example, the query

SELECT <newemp> e.name e.address.city </newemp>

FROM employees.emp e

returns the name and city of each employee.

3. Ability to Return an XML Document

The standard behavior of most query languages is to return a set of elements of some type. For an XML
query language the returned value should be an XML document. One possibility for returning an XML
document is to allow the query return value to be embedded within XML markup tags. For example, the
following query returns its results embedded within <result> </result> tags. The <result> </result> tags
could be applied implicitly if not explicitly associated with the query.

Query
<result>
SELECT <newemp> e.name </newemp>

35
 V-CHECK (ONLINE
R.T.O)

FROM employees.emp e
</result>

Query Result
<result>
<newemp>
<name>John Taylor</name>
</newemp>
<newemp>
<name>Sue Smith</name>
</newemp>
</result>

4. Ability to Query and Return XML Tags and Attributes

An XML data element contains data, a tag, and optionally, attributes. It is imperitave that an XML query
language be able to query the element tags and attributes as well as the data. Tags and attributes should be
able to be referenced in any part of the query--the SELECT clause, the FROM clause, and the WHERE
clause. For example, the following query selects all employees with a fax number and returns their name as
an attribute of the <newemp> element.

Query
SELECT <newemp name= e.name.value/>
FROM employees.emp e
WHERE e.phone.type = "fax"

Query Result
<newemp name= "Sue Smith"/>

Similarly, the following query "inverts" the employees' names and emp tags..

Query
SELECT <e.name> <recordtag>e.tag</recordtag> </e.name>
FROM employees.emp e

Query Result
<John Taylor>
<recordtag>emp</recordtag>
</John Taylor>

36
 V-CHECK (ONLINE
R.T.O)

<Sue Smith>
<recordtag>emp</recordtag>
</Sue Smith>

5. Intelligent Type Coercion

Since both textual and numeric data are represented as strings in XML, the query language should be
intelligent enough in comparison operations to determine whether a string comparison is intended or if a
coercion is required. For example, the following query requests all employees whose age is less than 100.
Even though "34" > "100" using a string comparison operator, it is clear from the query (since 100 is written
as a number) that the intent is to use a numeric comparison.

SELECT e
FROM employees.emp e
WHERE e.age < 100

The following query, however, suggests using string comparison, since 100 is written as a string.

SELECT e
FROM employees.emp e
WHERE e.age < "100"

6. Handle Unexpected Data

Data in XML does not have to conform to a fully-structured DTD. Therefore, it is critical that an XML
query language "do the right thing" in the face of unexpected data as much as possible. For example,
suppose that a query writer expected only a single occurrence of the phone element for each employee, and
so wrote the following query to return the employees whose phone number was "555-1234."

SELECT e
FROM employees.emp e
WHERE e.phone = "555-1234"

In order to handle employee elements having multiple phone elements (or no phone elements), the above
query should interpret the WHERE clause condition with an implicit existential quantification. That is,
"there exists an e.phone element x such that x = "555-1234."

7. Allow Queries When the DTD Is Not Fully Known

37
 V-CHECK (ONLINE
R.T.O)

It may often be the case with XML that the query writer understands a part of the DTD, but not in its
entirety. The query language needs to support wildcards in the path expressions to allow the query writer to
"skip past" parts of the document structure of which he or she is not aware. For example, suppose that the
query writer was uncertain as to the element tag for phone number (but knew it was either phone or number)
and the exact path leading to employee city. The following query allows the writer to return phone numbers
for all employees containing an element "Chicago." In the query a "*" represents any sequence of 0 or more
elements.

SELECT <newemp> e.(phone|number) </newemp>

FROM employees.emp e
WHERE e.* = "Chicago"

8. Return Unnamed Attributes

In restructuring information it is often useful to express things like "return all child elements," or "return all
child elements except this one." An XML query language should support queries that return elements even
when their tags are unknown. For example, the following query returns all employee child elements except
phone. In the query, a "^" is used similarly as in regular expression character classes to negate the set.

SELECT <newemp> e.(^ phone) </newemp>

FROM employees.emp e

9. Return Trees Instead of Sets

Although query languages usually return sets, when restructuring an XML document it is likely that the user
will want to have the query return a more nested structure. For example, suppose in our example database
the query writer wanted to reorganize the data so that employees were grouped by city within state. The
general idea would be to have a hierarchy of tags with cities embedded within state tags, and employees
embedded within city tags as in the following.

<state>
<statename>..</statename>
<city>
<cityname>..</cityname>
<emp>...</emp>
</city>
</state>

38
 V-CHECK (ONLINE
R.T.O)

One possibility for doing this would be to add a new construct, say "merge by," similar to group by in SQL,
that would take the elements returned from a select-from-where query and merge them according to
attributes. For example, the above structure might be specified as:

SELECT <state> <statename> e.address.state </statename> <city> <cityname> e.address.cityname

</cityname> e </city> </state>
FROM employees.emp e
MERGE state by statename, city by cityname

10. Preserve Order

SGML documents have an implicit order, and XML documents do as well. It is important for an XML query
language to be able to optionally guarantee that the order of returned results is the same as in the original
document. Perhaps an extension to the "order by" clause could be used for this purpose. For example,

SELECT e
FROM employees.emp e
ORDER BY document-order

39