ACDS AIMS Certified Database Specialist Course.

ACDS AIMS Certified Database Specialist Course.

Data Connectivity Learning Objectives 8 Be aware of the different techniques to connect an Access Data Page to different data providers among them: ODBC OLEDB ADO DAO Implement data connectivity by using Microsoft Access Pages, ADP files 8.1 Overview: ADP files A Microsoft Access project (.adp) is an Access data file that provides efficient, native-mode access to a Microsoft SQL Server database through the OLE DB or other component architecture. Using an Access project, you can create a client/server application as easily as a file server application. This client/server application can be a traditional solution based on forms and reports, or a Webbased solution based on data access pages, or a combination of both. You can connect the Access project to a remote SQL Server database, a local SQL Server database, or a local installation of SQL Server 2000 Desktop engine. Connects the Access project to the SQL Server database Database objects stored in the SQL Server database Database objects stored in the Access project An Access project is called a project because it contains only codebased or HTML-based database objects: forms, reports, the name and location of data access pages, macros, and modules. These are the database objects that you use to create an application.

Unlike a Microsoft Access database, an Access project does not contain any data or data definition based objects: tables, views, database diagrams, stored procedures, or user-defined functions. Instead, these database objects are stored in the SQL Server database. To create your application and access the data, you connect the Access project to the SQL Server database by using the New command on the File menu to display the Data Link Properties dialog box or by using the Database Wizard. Supported Microsoft SQL Server databases You can connect to one of the following SQL Server databases: Microsoft SQL Server 2000 on Microsoft Windows 2000 or later Microsoft SQL Server 2000 Desktop Engine on Windows 2000 or later Note: If you are connecting to a named instance of a SQL Server 2000 server, your Access project client computer must have Microsoft Data Access Components (MDAC) version 2.6 installed. You can install MDAC 2.6 by installing Microsoft SQL Server 2000 Personal Desktop Edition from the \MSDE2000 folder on the Microsoft Office 2003 CD-ROM. Working with an Access project is very similar to working with an Access database. The process of creating forms, reports, data access pages, macros, and modules is virtually the same as that used to create an Access database. Once you connect to an SQL Server database, you can view, create, modify, and delete tables, views, stored procedures, userdefined functions, and database diagrams by using the Database Designer, Table Designer, Query Designer, Query Builder, and SQL Text Editor. Although the user interface for working with these database objects is different from the equivalent database objects in an Access database, it is just as user-friendly. An Access project also contains many of the same wizards as an Access database, such as the Form Wizard, the Report Wizard, the Page Wizard, and the Input Mask Wizard. These Wizards help you to quickly create a prototype or simple application, and also make it easier to create an advanced application. If your Access project is connected to an SQL Server 2000 database, you can use and take advantage of extended properties. Extended properties store additional attribute information about SQL Server database objects that are stored in the SQL Server database and provide added functionality for an Access project such as: Creating a lookup on a column. Displaying user-friendly validation text. Formatting data and Defining input masks. Using subdatasheets, saving sort order and filters, and saving datasheet appearance of tables, views, stored procedures, and inline user-defined functions. Some extended properties are used by Access and are not visible through an Access project, such as a property which sets the column widths in a table datasheet. Other extended properties are available from the Database, Table, and Query Designers property sheets for views, single statement stored procedures (except column properties), and in-line functions.

Because multistatement stored procedures, and table and scalar user-defined functions are edited in the SQL Text Editor, they don't support extended properties. By default, SQL Server does not support extended property inheritance. A column in a view does not automatically have the same properties as the column in the base table. However, an Access project does support inheritance by copying the extended properties from table columns to view and function columns on creation, and by copying extended properties from table columns to form and report control properties. Changes to the extended properties of tables, views, stored procedures, and in-line functions are seen by all users of the database, because extended properties are stored in the SQL Server database. This means, for example, that if you change the format of a table datasheet, you are changing it for everyone who subsequently opens the table datasheet. Create an Access project On the File menu, click New. Do one of the following: Create a Microsoft Access project and connect it to an existing Microsoft SQL Server database In the New File task pane, under New, click Project (Existing Data). In the File New Database dialog box, click a location in the Save in box, and type a name in the File name box; make sure that Microsoft Access Projects appears in the Save as type box, and then click Create. On the Connection tab in the Data Link Properties dialog box, enter a server name and the information necessary to log on to the server, and then select the database on the server. For additional information, click Help in the Data Link Properties dialog box. Create a SQL Server database and connect an Access project to it In the New File task pane, under New, click Project (New Data). In the File New Database dialog box, click a location in the Save in box, and type a name in the File name box; make sure that Microsoft Access Projects appears in the Save as type box, and then click Create. In the Microsoft SQL Server Database Wizard, type the name of the server you would like to use, the logon ID and password of an account with CREATE DATABASE privileges on the server, and the name of the new SQL Server database. Click Next. If you are creating a Microsoft SQL Server 6.5 database, enter the database device and size, the transaction log device and size, the database size, and the log size. You don't need to specify devices and sizes for Microsoft SQL Server 7.0 or later. Click Finish. Create an Access project that is not connected to a Microsoft SQL Server database In the New File task pane, under New, click Project (Existing Data).

In the File New Database dialog box, click a location in the Save in box, and then type a name in the File name box; make sure that Microsoft Access Projects appears in the Save as type box, and then click Create. In the Data Link Properties dialog box, click Cancel.

Data Connectivity Architecture Data Consumers VC++ Application VB Application Office 2003 ASP Others Data Access Objects: DAO Active X Data Objects: ADO 2.5, ADO.NET Service Components Database Cursor Engine Jet ODBC 32 Jet ODBC 16 Simple Data Provider DBLIB,.NET native DAO ODBC SQL direct providers ODBC Mainframe Data Non Relational Data SQL DB Query Processor Jet 4.0 OLEDB OLEDB.Net Data Providers Oracle OLEDB OLEDB SQL Server OLEDB Providers Database Fernando Heredia AIMS MIS Consultant 2005

Data Access Objects: DAO: Old version for VB 6 VC++ 5 not supported anymore, but Version 3.60 still included in Access 2003. Bypasses the jet driver by using DAO ODBC Direct ODBC: Open Database Connectivity This is the oldest systems works only with databases Data Sources Name :.DSN files: Machine data sources: Information in the Windows Registry Two types: User data sources can be used only by the current user and are 1 visible only to that user. 2 System data sources can be used by all users on a computer and are visible to all services. File data sources: Information in text file Hands On: Control Panel/Admin tools/data connections Office 2003:Office Data Connection (ODC) File format that uses HTML and XML to store the connection information. Editable in notepad Active X Data Objects: ADO 2.5 and ADO. NET New standard in data connectivity management from VB, VC++, ASP,.NET; it uses mainly OLE DB data providers to take advantage of its versatility on data sources: The SQL Server.NET Data Provider: It communicates directly with SQL Server by using the native data transfer protocol of SQL Server. The Oracle.NET Data Provider. The OLE DB.NET Data Provider. The ODBC.NET Data Provider (Legacy) The Microsoft OLE DB Provider for Internet Publishing (FrontPage) The XML from SQL Server 2000 managed provider OLE DB: Object Linking and Embedding Database Newest framework works with all applications, not only databases, including Exchange. Standard data providers are: Jet 4.0 OLE DB OLE DB.Net Oracle OLE DB OLE DB for SQL Server Universal Data Link file.uld File: file-persistent OLE DB data source object definitions. Hands On: Access/ New project or New Access Page/Connection Fernando Heredia AIMS MIS Consultant 2005

Data Access Stack for ADO.NET Fernando Heredia AIMS MIS Consultant 2005

Most applications require some form of data access. If you are creating a new application, you have three excellent data access choices: ADO.NET, ADO, and OLE DB. If you need to modify the data access for an existing application, you might continue using the application's current data access technology for maintenance convenience. However, if you expect the application to have a long lifecycle, you should consider reengineering to use either ADO.NET for managed applications or ADO for native applications. In the long run, the newer data access technologies typically reduce development time, simplify code, and provide excellent performance. 8.2 ODBC An ODBC data source (ODBC data source: Data and the information needed to access that data from programs and databases that support the Open Database Connectivity (ODBC) protocol.) for example, a database and the server on which it resides is accessed through an Open Database Connectivity (Open Database Connectivity (ODBC): A standard method of sharing data between databases and programs. ODBC drivers use the standard Structured Query Language (SQL) to gain access to external data.) (ODBC) driver. A data source is a source of data and the connection information needed to access that data. Examples of data sources are Microsoft Access, Microsoft SQL Server, Oracle RDBMS, a spreadsheet, and a text file. Examples of connection information include server location, database name, logon ID, password, and various ODBC driver options that describe how to connect to the data source. In the ODBC architecture, an application (such as Access or a Microsoft Visual Basic program) connects to the ODBC Driver Manager, which in turn uses a specific ODBC driver (for example, Microsoft SQL ODBC driver) to connect to a data source (in this case, a Microsoft SQL Server database (SQL database: A database that is based on Structured Query Language (SQL).)). In Access, you use ODBC data sources to connect to data sources external to Access that do not have built-in drivers. To connect to these data sources, you must do the following: Install the appropriate ODBC driver on the computer that contains the data source. Define a data source name (DSN) by using either the ODBC Data Source Administrator to store the connection information in the Microsoft Windows registry or a DSN file, or a connect string in Visual Basic code to pass the connection information directly to the ODBC Driver Manager. Machine data sources Machine data sources store connection information in the Windows Registry on a specific computer with a user-defined name. You can use machine data sources only on the computer they are defined on. There are two types of machine data sources user and system. User data sources can be used only by the current user and are visible only to that user. System data sources can be used by all users on a computer and are visible to

all users on the computer and system-wide services, such as Microsoft Windows services. A machine data source is especially useful when you want to provide added security, because it helps ensure that only users who are logged on can view a machine data source and it cannot be copied by a remote user to another computer. File data sources (also called DSN files) store connection information in a text file, not the Windows registry, and are generally more flexible to use than machine data sources. For example you can copy a file data source to any computer with the correct ODBC driver so that your application can rely on consistent and accurate connection information to all the computers it uses. Or you can place the file data source on a single server, share it between many computers on the network, and easily maintain the connection information in one location. A file data source can also be unshareable. An unshareable file data source resides on a single computer and points to a machine data source. You can use unshareable file data sources to access existing machine data sources from file data sources. Connect strings If you are a programmer, you can define a formatted connect string in your Microsoft Visual Basic code that specifies the connection information. Using a connect string avoids defining a machine or file DSN and passes the connection information directly to the ODBC Driver Manager. This is useful, for example, when you want to avoid requiring system administrators or users to first create a DSN, or to simplify the installation of your application. To maintain security for the connection string information in your code, help protect your code by using a MDE file or protecting your code with a password. Security Note Use strong passwords that combine upper- and lowercase letters, numbers, and symbols. 8.3 OLEDB OLE DB is the strategic system-level programming interface for accessing data, and is the underlying technology for ADO as well as a source of data for ADO.NET. OLE DB is an open standard for accessing all kinds of data both relational and non-relational data including: mainframe ISAM/VSAM and hierarchical databases; e-mail and file system stores; text, graphical, and geographical data; and custom business objects. OLE DB provides consistent, high-performance access to data and supports a variety of development needs, including the creation of front-end database clients and middle-tier business objects using live connections to data in relational databases and other stores. Choosing OLE DB The choice to write to OLE DB directly must be evaluated against using an easier data access method such as ADO.NET or ADO. The factors affecting your decision to use OLE DB's COM-level data access include: ACDA AIMS Certified Database Assistant Course. 10

Performance Both ADO.NET and ADO are very fast, but they do insert an extra layer of abstraction between your application and the data provider when working with OLE DB data sources. If Microsoft SQL Server is your back-end database, and you are writing in managed code, the.net Framework Data Provider for SQL Server will yield the best performance since it bypasses the overhead imposed by ADO and OLE DB and communicates with the server directly via the network driver. If performance is an issue against a non-sql Server database, you might decide to code in Visual C++ using OLE DB. You might have additional options through other 3rd-party data providers. Functionality OLE DB defines native interfaces designed to be extensive and extensible enough to expose all of a database's underlying behavior, semantics, and functionality. ADO exposes a subset of the common functionality defined by the OLE DB interfaces, and ADO.NET provides common objects for working with data that hides differences between the behavior, functionality, and type systems of the different sources. If you need to access the native behavior, functionality, and data types of a particular database, OLE DB provides the most comprehensive native interface to the data source. Maintenance Using the OLE DB data access technology affects the cost of long-term maintenance for your application. Using OLE DB is more expensive than either ADO.NET or ADO because maintaining and enhancing complex code is more difficult. Developer skill Native coding in the COM environment requires considerable programming skill. Writing to the OLE DB interface is a very complex and difficult task. If your staff has OLE DB and COM expertise, you might choose OLE DB and capitalize on that experience. Language If you choose OLE DB for your data access technology, you must program using Visual C++. You can make the programming a bit easier by using the consumer and provider templates in the OLE DB Templates library. For more information, see OLE DB Templates. If your application requires the high performance and raw manipulative power of OLE DB, you have the skill to write to a system-level programming interface, and are willing to pay for the more expensive long-term maintenance burden, then OLE DB is a good choice. For more information on using OLE DB for data access, see OLE DB Programming. 8.4 ADO, ADO.NET ADO.NET ADO.NET is the strategic application-level interface for providing data access services in the Microsoft.NET Platform. You can use ADO.NET to access data sources using the new.net Framework data providers. These data providers include:.net Framework Data Provider for SQL Server..NET Framework Data Provider for OLE DB..NET Framework Data Provider for ODBC..NET Framework Data Provider for Oracle. These data providers support a variety of development needs, including middle-tier business objects using live connections to data in relational databases and other stores. ACDA AIMS Certified Database Assistant Course. 11

ADO.NET is designed specifically for message-based Web applications while still providing preferable functionality for other application architectures. By supporting loosely coupled access to data, ADO.NET maximizes data sharing by reducing the number of active connections to the database reducing the possibility of multiple users contending for limited resources on the database server. ADO.NET provides several ways to access data. If your Web application or XML Web service requires data access from multiple sources, needs to interoperate with other applications (both local and remote), or can benefit from persisting and transmitting cached results, the dataset is an excellent choice. As an alternative, ADO.NET provides data commands and data readers to communicate directly with the data source. Direct database operations using data commands and data readers include running queries and stored procedures, creating database objects, and performing direct updates and deletes using DDL commands. ADO.NET maximizes data sharing by supporting an XML-based persistence and transmission format for the fundamental object of distributed ADO.NET applications: the dataset. A dataset is a relational data structure that can be read from, written to, or serialized using XML. ADO.NET datasets make it easy to build applications that require loosely coupled data interchange between application tiers and multiple Web sites. Because datasets are remoted as XML, any two components can share data and use XML schemas to define the relational structure of the dataset. And, because the dataset's serialization format is XML, DataSet objects can easily pass through firewalls without restrictions. In addition to loading data from XML, datasets can be populated with, and hold changes to, data from SQL Server as well as data sources exposed via OLE DB. A primary characteristic of a dataset is that you can access and manipulate the data inside a local dataset two ways: As tables in a relational database A dataset can contain one table or a collection of tables. An important aspect of the dataset is that it keeps track of the relationships between the tables it contains as if it is an in-memory relational data store. As XML (extended Markup Language) structures Data within a dataset can also be accessed as XML data. Methods are provided for reading and writing data as XML, and reading and writing the structure of the dataset as XML schema. In addition, an XmlDataDocument can be associated with a dataset in order to allow simultaneous viewing, querying, and modifying the data as XML. For detailed information on when to use ADO.NET data access technology, see the Decision Chart recommendations and the following individual topics: Introduction to Distributed Applications and Data Integration, Web Data Access Strategy Recommendations, Overview of ADO.NET, Accessing Data with ADO.NET, ADO.NET Datasets, Performing Database Operations Directly, Creating and Using Datasets. ADO For applications written in native code, ADO provides a COMbased application-level interface for OLE DB data providers. Similar to ADO.NET, ADO supports a variety of development needs, ACDA AIMS Certified Database Assistant Course. 12

including the creation of front-end database clients and middle-tier business objects using live connections to data in relational databases and other stores. And, like ADO.NET, ADO can construct client-side recordsets, use loosely coupled recordsets, and handle OLE DB's data shaping rowsets. ADO also supports some behaviors not exposed through ADO.NET, such as scrollable, server-side cursors. However, because server-side cursors require holding database resources, their use might have a significant negative impact on the performance and scalability of your application. In order to transmit ADO recordsets through firewalls you need to configure the firewall to enable the COM marshaling request, taking into account the associated security ramifications. COM marshaling also limits data types to those defined by the COM standard. Optionally, you can persist an ADO recordset in an XML format and transmit the XML text instead. For more information on COM data types, see COM Data Types. For more information, see Programming ADO SQL Server Applications. Choosing ADO.NET or ADO Both ADO.NET and ADO are easy to program, languageindependent, implemented with a small footprint, use minimal network traffic, and require few layers between the application's front-end and the data source. Both methods provide highperformance data access. Choosing either of these data access technologies affects an application's design, extensibility, interoperability, ease of maintenance, and many other factors. These include: Managed code If your application is written in managed code and built upon the common language runtime, you should use ADO.NET. If you are writing unmanaged code in C++ (and especially if you are maintaining an existing ADO application), ADO is still a good choice. Data structure The ADO.NET dataset can contain one or more tables, and provides both a table-based relational view and an XML-based view. The dataset uses standard common language runtime types, which simplifies programming. The ADO recordset is a single table, accessible only as a recordset, and does not contain relationships. An ADO recordset can be the result of a multiple table JOIN query, but it is still only a single result table. If you want multiple tables with ADO, you must have multiple Recordset objects. The ADO.NET dataset provides better functionality due to its integrated relational structure. Data sharing ADO.NET provides the basis for data interchange between components and across tiers: datasets can be passed over the Internet and through firewalls as XML. You can view the same set of data as relational tables within your application and as an XML data structure in some other application. The dataset provides convenient two-way transformation: from dataset tables to an XML document, and from an XML document into dataset tables. If you use COM marshaling to transmit an ADO recordset, the target application must be programmed to use the recordset data structure. This requires more difficult programming than simply reading XML data. Alternatively, you can persist the ADO recordset as XML and more easily share the data with other applications and services. ACDA AIMS Certified Database Assistant Course. 13

Scalability ADO.NET is the most scalable solution. ADO.NET is designed from the ground up to be the best data access architecture for building scalable Web applications with a low total cost of ownership. If you do not need the scalability, and are not writing in managed code, you can continue to use ADO. Cursor location An application can establish result sets in either of two places: within the application process (client-side cursor) or within the data store process (server-side cursor). Client-side cursors are generally a good choice for any type of impromptu user interaction with the data. Client-side cursors are supported in ADO.NET by the DataSet object and in ADO by the ClientCursor Recordset object. Sequential, read-only server cursors are supported in ADO.NET by data readers (such as the SqlDataReader or OleDbDataReader objects), and in ADO by a forward only/read-only Recordset object. Sequential, read-only cursors provide the fastest means of reading data out of a database. Scrollable, updatable server-side cursors are supported in ADO by a scrollable, updatable Recordset object. Server-side cursors should be used cautiously. Non-sequential scrolling and updating of results through a server-side cursor holds locks and causes resource contention that greatly limits scalability of the application. In place of using a scrollable, updateable server-side cursor, an application can generally benefit from the use of stored procedures for procedural processing of results on the server. Data access connection Both ADO.NET and ADO support explicit connections to the database. In ADO.NET, the developer might use a data reader, holding locks based on the current position and requiring a continuous connection to the database until the data is read. Alternatively, the data could be put into a dataset. When using a dataset, the developer can choose whether to keep the connection and transaction open while the data in the dataset is being modified, or open the connection and use transactions only when needed to populate data into the dataset and update changes back to the database. Closing the connection frees resources and locks for other users while the data in the dataset is being transmitted, viewed, and modified. In ADO, Recordsets can use either an open connection and hold locks as the user reads through the data in the database, or a client cursor Recordset can work with data without holding a database connection. Data scrolling Both ADO.NET and ADO can navigate data sequentially and non-sequentially. With the ADO.NET dataset you can also conveniently navigate from a row in one data table to the related rows in another table. Both the ADO recordset and the ADO.NET data readers support very fast, forward-only, read-only server-side cursors. The ADO recordset uniquely supports scrollable, updateable server-side cursors, although such cursors consume server resources and in most cases can be better implemented as logic within a stored procedure or as a loosely coupled client-side cursor. Ease of use The ADO.NET dataset provides self-describing data and removes the need to handle underlying data constructs such as tables, columns, constraints, and rows. Instead, with the dataset you have type-safe access to data using objects. This makes programs easier to read, write, and modify. Because application tiers can exchange data through XML-formatted datasets, new and extended communication is easily implemented over the lifecycle of the application. With ADO.NET, it does not matter which language you use for data access: they are all syntactically similar and use the same common language runtime services. ACDA AIMS Certified Database Assistant Course. 14

While both ADO.NET and ADO support loosely coupled data access, there is a difference. With ADO.NET you can control how the dataset changes are transmitted to the database by modifying the statements used by the DataAdapter object, or by inserting custom code that responds to row updating events. With this feature you can optimize performance, modify validation checks, or add any other extra processing all without changing your application. For more information, see Issues in.net Application Architecture. 8.5 DAO 3.6 DAO 3.5 introduces a client/server connection mode, called "ODBCDirect." ODBCDirect establishes a connection directly to an ODBC data source, without loading the Microsoft Jet database engine into memory, and is useful in situations where specific features of ODBC are required. It is recommended to use ADO /ADO.Net technologies once DAO are older and less compatible with the.net framework. ACDA AIMS Certified Database Assistant Course. 15

Acknowledgements This training material has been compiled, edited and created from different sources by: Ghulam Haider "Rahamanzoi" Fernando Heredia UNDP/AIMS MIS Database Trainer Kabul UNDP/AIMS MIS Consultant Kabul ghulam.haider@aims.org.af fernando.heredia@aims.org.af Haider_reh@hotmail.com fhpjobs@yahoo.com +93 079 32 15 14 +93 070156701 Contact AIMS Afghanistan information management services Capacity Building Initiative Next to Inhessarat Building 12 Salang Watt, Kabul, Afghanistan Phone (1-512) 329 8027 Fax (1-512) 329 8321 E-mail: info@aims.org.af http://www.aims.org.af/ ACDA AIMS Certified Database Assistant Course. 16