Hướng dẫn học Microsoft SQL Server 2008 part 91 docx

Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 862
Part V Data Connectivity
tab, add a provider for each output type that will be logged (multiple are allowed). On the Details tab,
specify the events for which log entries will be written; the advanced view, shown in Figure 37-6, also
allows selecting which columns will be included in each event’s log entry.
FIGURE 37-6
Advanced view of the Logging Details tab
The tree view in the left pane represents the container hierarchy of the package. The check boxes
correspond to each object’s
LoggingMode property: clear for Disabled, a black check for Enabled,
and a gray check for
UseParentSetting (logging settings inherited from the parent). By default,
all objects inherit from the package settings. Highlighting an item in the tree displays the details
for that o bject in the current tab. Note that providers can only be configured for the package, and
any object with
UseParentSetting will have its options grayed out in deference to its parents’
settings.
862
www.getcoolebook.com
Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 863
Performing ETL with Integration Services 37
The standard log providers are as follows:
■ Text File: Writes a comma-separated-value text file. Configure with an appropriate File
connection manager.
■ SQL Profiler: Writes a .
TRC file that can be viewed in the Profiler application. This can be
a useful option when viewed with other trace or performance information within Profiler.
Configure with an appropriate File connection manager.
■ SQL Server: Writes log entries to the
dbo.sysssislog table in the database indicated by
the associated OLE DB connection manager. Any database can be chosen to host this table. If

the table does not exist, then i t will be created on first use.
■ Event Log: Writes log entries to the Windows application event log on the computer that
executes the package. No configuration is required.
■ XML File: Writes an .
XML file. Configure with an appropriate File connection manager.
Once a useful set of event/column combinations has been constructed, it can be saved as a template and
reloaded on other packages.
Package configurations
Package configurations make it easier to move packages between servers and environments, providing
a way to set properties within the package based on environment-specific configurations. For example,
the server names and input directories might change between the development and production
environments.
Right-click on the package design surface and choose Package Configurations to setup/modify con-
figurations. The configurations shown are applied to the package i n the order listed. To add a new
configuration, ensure that configurations are enabled and click Add to start the Package Configuration
Wizard. Choose the desired Configuration Type (storage location). There are essentially three categories
to consider:
■ Registry and E nvironment Variable: These types can hold a single property only.
■ XMLFileandSQLServerTable:Each of these configuration types can hold any number of
property settings.
■ Parent Package V ariable: Allows access to the contents of a single variable from the calling
package.
Most configuration types allow the storage l ocation to be identified either directly or via an environment
variable. The environment variable approach can be useful when the storage location (such as file direc-
tory) must change between environments. Once the configuration type and location are specified, the
Select Properties to Export option enables the properties that will change between environments to be
chosen. Complete the wizard by reviewing the selections and giving the configuration a name.
Configurations can be reused between packages if the names of the objects containing the properties to
be set are the same between packages. For example, packages that use the same names for their con-
nection managers could share a configuration that sets server or filenames. To share a configuration in

863
www.getcoolebook.com
Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 864
Part V Data Connectivity
a subsequent package, choose the same configuration type, and then specify the same storage location
(e.g., XML filename) as the initial package. When prompted by a dialog warning that the configuration
already exists, select Reuse Existing.
Checkpoint restart
Enabling checkpoint restart allows a package to restart without rerunning tasks that already completed
successfully. Note the following basic rules about restart points:
■ Only Control Flow tasks define restart points — a Data Flow task is viewed as a single unit of
work regardless of the number of components it contains.
■ Any transaction in progress is rolled back on failure, but the restart point may not coincide
with a transaction boundary, so unexpected results can occur.
■ Any loop containers are started over from the first iteration.
■ Theconfigurationusedonrestartissavedin the checkpoint file, rather than the current
configuration file.
Enable checkpoints by setting the package properties:
■ CheckpointFilename: Name of the file in which checkpoint information should be saved
■ CheckpointUsage: Set to either
IfExists (starts at the beginning of the package if no file
exists or at the restart point if the checkpoint file exists) or
Always (fails if the checkpoint file
does not exist).
■ SaveCheckPoints: Set to
True.
In addition, the
FailPackageOnFailure property must be set to True for the package and every
task or container that can act as a restart point.
Deploying Packages

The Business Intelligence Development Studio is an excellent environment for designing and debugging
Integration Services packages, but it is not an efficient method for routinely executing packages.
Without installing a package on a server, it can execute without the development overhead by using
dtexec/dtexecui. You can run dtexecui from the command line, or you can choose the Execute
Package Utility from the Start menu, and specify the desired execution options. Then either choose the
Execute button or switch to the Command Line page to copy the appropriate
dtexec command-line
switches.
Conversely, installing packages on the target SQL Server(s) makes sense when a package will be reused.
Once installed, a package is known to the Integration Services service, which in turn can be connected
to SQL Server Management Studio for tracking and monitoring. Integration Services also caches the
components executed b y packages to reduce startup time.
864
www.getcoolebook.com
Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 865
Performing ETL with Integration Services 37
Installing packages
Creating a deployment utility enables the i nstallation of all the packages in a project on a target server.
Configure the utility by right-clicking on the project (not the package) in the Solution Explorer a nd
choosing Properties. Navigate to the Deployment Utility page of the resulting dialog and set the value
of
CreateDeploymentUtility to True. Review the settings for DeploymentOutputPath
indicating where the install package will be written relative to the project directory, and the setting of
AllowConfigurationChanges, which enables configuration values to be adjusted as part o f the
install process. Save the property changes, and then right-click on the project and choose Build to create
the install package.
Once the deployment utility has been created, double-click the package manifest
(<project
name>.SSISDeploymentManifest
) to start the package installation. Given a network

connection to the target server and adequate permissions, the installation can be run from any
machine.
In addition, individual packages can be installed on a server using SQL Server Management Studio. Log
on to the target server and connect the local instance of Integration Services in the Object Explorer. On
either the File System or msdb nodes, right-click and choose Import Package. Note that the source pack-
age can be stored either as a file or as a SQL Server (msdb) package. Similar functionality is available
from the
dtutil command-line utility.
Executing packages
Once installed on the target server, a package can be executed in several ways:
■ Locate the installed package in SQL Server Management Studio, right-click, and choose Run
Package, which in turn invokes
dtexecui for the selected package.
■ Run the
dtexecui utility, which enables the full array of execution options to be selected. It
also displays the command-line switches to use with the
dtexec command-line utility.
■ From a SQL Agent Job step, choose the step type as SQL Server Integration Services Package,
and the package source as SSIS Package Store.
The execution method and location that you choose can have a profound effect on performance and
reporting. Execution using
dtexec/dtexecui can offload package processing from the SQL Server
when run on another server or workstation. These options also default to providing verbose feedback
during execution, which can be useful in tracking progress or understanding errors. However, consider
network traffic that may be introduced by this scenario. For example, loading a series of data files
from a file server to the SQL Server via a workstation can double the network load (every file must
move from the file server to the workstation, and then again from the workstation to the SQL Server)
compared to running the package on the SQL Server.
Running a package via the SQL Agent causes the package to execute on the SQL Server, which tends to
minimize network load, but this can be a problem if the SQL Server does not have adequate resources

to accommodate the often memory-hungry package.
865
www.getcoolebook.com
Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 866
Part V Data Connectivity
Summary
Integration Services is a capable environment for building applications that move large quantities of data
efficiently and for sequencing multi-step processing with error handling. Management features such as
easy installation, a uditing and logging facilities, and environment-specific configurations make Integration
Services applications easy to live with once developed.
Many organizations have written reams of Transact-SQL and programmed custom applications to address
tasks that Integration Services handles with ease. For those willing to make a small investment in learn-
ing the Integration Services environment, the c ost savings and performance gains can be truly stunning.
The best way to get started is to choose a small project and dive in. Like any programming envi-
ronment, the first application won’t be perfect, but soon you’ll wonder how you ever lived without
Integration Services.
866
www.getcoolebook.com
Nielsen c38.tex V4 - 07/23/2009 4:01pm Page 867
Access as a Front End
to SQL Server
IN THIS CHAPTER
Access–SQL Server use case
scenarios
Migrating from Access to SQL
Server
Designing your Access front
end
Connecting to SQL Server
Monitoring and

troubleshooting
Ad hoc querying and reporting
A
ccess was originally conceived a s a standalone desktop database product,
combining in one file a relational database engine (Jet) as well as user
interface objects, such as forms, reports, macros, designers, and a VBA
coding environment. Its very name, Access, denoted one of its most powerful
features: the ability to easily incorporate data originating from heterogeneous
data sources. When Access was introduced, installable ISAM drivers were used
primarily for linking to the prevailing desktop databases, such as Paradox, dBase,
and FoxPro, or to Lotus and Excel spreadsheets. An ODBC installable ISAM
enables connecting to many server-based database systems, such as SQL Server
and Oracle, and additional drivers have been added to connect to Microsoft
Exchange Server data and to HTML tables. In Access 2003, Windows SharePoint
Services support was added, which enabled linking to SharePoint lists, allowing
them to be queried and updated as if they were standard relational tables.
Access 2007 introduced a new version of the Jet database engine, ACE, which i s
designed to support Access-specific features but is 100% backward compatible
with Jet. When it comes to the mechanics of working with SQL Server, the
underlying architecture is fundamentally the same a s it was in Jet, so regardless
of which version of Access you are using, the techniques for working with SQL
Server data described in this chapter apply, except where otherwise noted.
The Access 2007 user interface is designed to make working in the Access
environment more intuitive for information workers, providing a more Excel-like
experience in datasheet view, introducing powerful new filtering, sorting, and
totaling features, along with improved designers for forms and reports.
For more in-depth information and ideas for getting
the most out of using Access 2007 as a front end for
your SQL Server data, see the Microsoft Office Access Vision white paper,
/>867

www.getcoolebook.com
Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 868
Part V Data Connectivity
Access–SQL Server Use Case Scenarios
Using Access as a front end to SQL Server can be an optimal solution for a wide variety of business
problems, often delivering the best return on investment while meeting the business requirements. The
following are several scenarios in which Access has proven to be effective:
■ The business problem does not warrant the expense of a full-fledged, end-to-end .NET
solution.
■ You want to empower users to solve their own problems. For example, executives and power
users want to access server data to run their own analytics and create ad hoc reports.
■ You need to deliver a solution in a time frame that does not allow for a lengthy development
process.
■ You work in an agile, iterative programming environment, and Access enables you to deliver
prototypes quickly.
■ Your application exists behind the corporate firewall where users are authenticated by
Windows.
■ You use Access as part of a hybrid application, such as a customer-facing web application
created in ASP.NET with a data maintenance component that uses Access.
■ You work with heterogeneous data from different vendors or data stores. For example, cus-
tomer data is stored in relational SQL Server tables, while internal data may be stored in
SharePoint lists. Access makes it simple to create data entry forms and reports based on
queries that join this heterogeneous data.
Access projects or ODBC linked tables?
Access project files, also called ADPs or .adp files, provide an alternative to using the Access database
engine by allowing an Access application to connect to the tables in a SQL Server database using OLE
DB as an alternative to the Jet engine, which connects to SQL Server using ODBC. Because ADPs do not
use a local database engine, they a lso do not support the use of local Access tables.
ADPs also provide visual designers for creating database objects in SQL Server. However, these features
can become outdated as new versions of SQL Server are released. Microsoft recommends the use of

Access databases with ODBC linked tables to connect to SQL Server data, which gives you the best
performance in most situations and the widest set of features. For creating server-side objects, Microsoft
recommends that you use a version of SQL Server that contains SQL Server Management Studio.
If you are an Access developer who does not have access to one of the full versions of SQL
Server, the SQL Server Developer Edition, which is priced at $49 U.S., contains all of the
features and functionality of the Enterprise Edition. It has all the designers and tools you need to create
and secure your server-side data objects, although there are some licensing restrictions.
Migrating from Access to SQL Server
Successful Access database applications outlive their usefulness for a variety of reasons, and at some
point you may decide that it’s time to upgrade to a server database. Or perhaps your application has
868
www.getcoolebook.com
Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 869
Access as a Front End to SQL Server 38
become indispensable to the business, and you need server-side features such as security, support for
larger numbers of concurrent users, and reliability.
Migrating to SQL Server is not a panacea for problems that may have existed in the original Access
application. In fact, the exact opposite is often true. It is not uncommon for a straight port of an
Access application to run much more slowly when the data is in SQL Server. The Access Jet/ACE
database engine and the SQL Server database engine are quite different, and what worked well in your
Access application can cause problems when the data is moved to the server. Performance problems are
magnified, not reduced, when server and network overhead are added to the mix.
You need to diagnose and thoroughly understand an y problems with your Access a pplication before you
dive into migrating. Often issues like database corruption and poor performance can be fixed by taking
simple measures to solve the problem in Access, removing the need to do a migration at all. In other
cases, a complete rewrite from the ground up is required. Thoroughly understanding the problem will
help you make the right decision, saving you time and money.
Once the decision is made, migrating data is actually the easiest and least complicated part of the
process.
Resources for Migrating from Access to SQL Server

R
ather than rewrite it all, some great resources are already available that will help you plan and implement
a migration:
■ Microsoft Access or SQL Server: What’s Right in Your Organization? http://
download.microsoft.com/download/a/4/7/a47b7b0e-976d-4f49-b15d-
f02ade638ebe/SQLAccessWhatsRight.doc
■ The SQL Server Migration Assistant for Access (SSMA Access) starter videos and FAQ
www.microsoft.com/sqlserver/2005/en/us/migration-access-
learning.aspx
■ Move Access data to a SQL Server database by using the Upsizing Wizard http://
office.microsoft.com/en-us/access/HA102755371033.aspx?pid=
CH101759711033
■ Use the Upsizing Wizard (Access 2003) />access/HP052730091033.aspx
■ SQL Server Integration Services (SQL Server 2008 Books Online) http://msdn
.microsoft.com/en-us/library/ms141026.aspx
■ Microsoft Access to SQL Server Upsizing Center (resources from FMS, Inc.) www
.fmsinc.com/Consulting/sqlserverupsizing.aspx
869
www.getcoolebook.com
Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 870
Part V Data Connectivity
Designing Your Access Front End
When creating an Access application that connects to SQL Server, use the same general design principles
that you would if you were creating a web application. Here are a few general suggestions:
■ Fetch only needed data. Do not link to large tables or views.
■ Perform data processing on the server, not the client.
■ Normalize your database and create appropriate indexes.
■ Do not use
SELECT * without a WHERE clause, or allow users to do so. Create q uery-by-form
user interfaces that force users to select criteria that reduce the size of result sets.

■ Populate form elements such as list boxes and combo boxes when a user clicks on the control,
not when the form loads. Otherwise, if you have a bound form with six combo boxes, then
Access must run seven concurrent queries when the form opens.
■ Take advantage of local Jet/ACE storage to cache static data that rarely changes.
■ For editing data, create browse forms populated with read-only data. When the user selects a
row to e dit, load it read/write in a separate form.
■ When creating reports, use pass-through queries to execute stored procedures, views, or
user-defined functions that process aggregate data on the server.
■ Do not use Access expressions or functions in queries. The function must run once for
every row retrieved, slowing down processing. If you want to format the data, do so using
expressions bound to form or report controls.
■ If you want users to be able to create their own ad hoc queries without negatively impacting
OLTP operations, create a separate set of ‘‘reporting tables’’ that they can query instead of the
tables used in production. Reporting tables can be refreshed in the background or on demand.
If you want to maximize the performance and scalability of your Access–SQL Server
applications, or just want a deeper understanding of the interactions between Access and
SQL Server, the white paper ‘‘Optimizing Microsoft Office Access Applications Linked to SQL Server’’
(
is indispensable. Many pitfalls can be
avoided by understanding how Access interacts with SQL Server, freeing you to create rich Access client
applications quickly and easily while treading lightly on your SQL Server.
Connecting to SQL Server
There are several ways you can interact with SQL Server data from an Access client application:
■ Through linked tables and views in the user interface
■ Programmatically using VBA/ADO
■ Using pass-through queries to bypass the Jet/ACE database engine. Pass-through queries are
written in Transact-SQL and are passed directly to SQL Server without being syntax checked
or parsed by Jet/ACE or ODBC. They always return read-only data.
870
www.getcoolebook.com

Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 871
Access as a Front End to SQL Server 38
Linking to tables and views
When you connect to a SQL Server database using the Access user interface, a wizard loads, prompting
you for information about the ODBC database to which you want to connect. You have the option to
import the data into a new table in the current Access database, or to link to the data source by creating
a linked table. The wizard then asks you to select an ODBC driver (see Figure 38-1). If you are using
SQL Server 2008, choose the SQL Server Native Client 10.0 driver.
FIGURE 38-1
Use the External Data tab on the ribbon to access the ODBC Administrator and specify a DSN to
connect to SQL Server.
You are then prompted for additional information, such as the database name. Once the DSN is created,
Access displays a list of tables to which you can link. You can then select one o r more tables, which are
displayed in the Access user interface using the underscore character to separate the schema name from
the object name. For example, Sales.SalesOrderHeader will be displayed as Sales_SalesOrderHeader. If
you are linking to a view, you will be prompted to designate a primary key, which Access requires in
order for the view to be updatable.
Using DSNs to link to SQL Server tables is fine for quick-and-dirty linking, but DSNs are difficult to
manage, so for applications you deploy to your users you may prefer to link using VBA code. There are
several advantages to this:
■ You can prompt the user for specific connection information, such as the name of a server or
database.
■ If you are using SQL logins, you can prompt for user credentials to avoid storing them on the
local machine.
■ You do not need to worry about copying o r maintaining DSNs on different machines.
871
www.getcoolebook.com