Tải bản đầy đủ - 0 (trang)
1-14. Importing Access Data as Part of a Regular ETL Process

1-14. Importing Access Data as Part of a Regular ETL Process

Tải bản đầy đủ - 0trang

CHAPTER 1 ■ Sourcing Data from MS Office Applications

Figure 1-23.  An SSIS Connection Manager for Access


Click OK to return to the OLEDB Source Editor.


Select Table or View as the data access mode.


Select the Access table from which you wish to import data.


Click OK to return to the Data Flow pane.


Add an OLEDB destination component to the Data Flow pane, and connect the

source component to it. Double-click the destination component to edit it.


Select the OLEDB connection manager named CarSales_OLEDB, which you created in

step 2 as the OLEDB connection manager to use.



CHAPTER 1 ■ Sourcing Data from MS Office Applications


Click New to create a new destination table. Change its name to suit your



Click Mappings on the left of the dialog box, and ensure that all fields are mapped,

either by dragging them from the available source columns to the available

destination columns, or by right-clicking Name in the available source columns,

followed by “Map items by matching names”.


Click OK to finish.

You can now run your import process and load the data.

How It Works

Here I am presuming that you are probably using SSIS to handle most of your industrial-strength ETL

requirements. After all, this product was developed precisely to satisfy such requirements. As is the case with

other methods of performing data import from Access sources, the choice of driver is important. Consequently,

I can only recommend always using the latest ACE driver, as it will handle all versions of Access from ’97 upward.

ACE is not the only game in town, and I have worked in many environments where Access 97–2003 was the

preferred Access file format for reasons of standardization and portability. So it is worth learning how to use the

Jet driver to read these files—if only because it is so simple to do.

Essentially, you follow steps 1–7, and then select the Native OLEDB Microsoft Jet 4.0

OLEDB Provider.

Click Browse to select the path and file name of the Access source database.

Then continue with steps 10–19.

There are several potential hurdles to overcome when you are using SSIS with the (32-bit) Jet driver in a

64-bit environment. As previously mentioned, when you install Integration Services on a 64-bit Windows Operating

System, it normally installs both the 32-bit and the 64-bit versions of the DTExec.exe executable, which is used

to execute SSIS packages. The problem is that SSIS may use the wrong one—especially when developing and

debugging SSIS packages with BIDS/SSDT. This is because BIDS/SSDT is a 32-bit development environment, so

if your SSIS package is referencing any 32-bit DLL or 32-bit drivers, then you must use the 32-bit executable—and

BIDS/SSDT tries to use the 64-bit version.To get around this, carry out the following steps:


Click Project ➤ (Your Project Name) Properties.


Select Debugging from the configuration properties.


Change Run64BitRuntime to False. The dialog should look something like Figure 1-24.




Figure 1-24. Setting the 64-bit runtime in SSIS

A classic problem, once our package is built tested and deployed on a 64-bit server, is to have an Access (or Excel)

data load fail in production. This failure is accompanied by a host of error messages that give no indication of the real

problem, which is that SSIS is (naturally) running the 64-bit DTExec.exe—which cannot use a 32-bit Jet driver.

There are a couple of classic solutions to this.


Separate out the Access data load part of your project into a separate SSIS package

(if this is not already done).


Call it from the main SSIS package, not by using an Execute Package task, but rather

by using an Execute Process task.


In the Execute Process Task, click Process in the left pane.


Click Executable and enter (in double quotes) the path to the 32-bit DTExec.


Follow this with a space, then the path to the SSIS package to run.

If you are using an Access 97–2003 database that has workgroup protection, and you cannot use a

unprotected database, then there are a couple of solutions. The first approach is as follows:


When defining the connection manager for Access at step 10 in the main recipe, use

the workgroup login/password as the username and password.


Click All in the left of the dialog box and enter or copy the full path and filename of the

workgroup file for the Jet OLEDB:System Database parameter.

The second possibility is more of a workaround. You have to link, import, or export the table data to a new

Access database and point SSIS to that.

Of course, you can use an existing destination table if one exists. Equally, you may prefer to create the

destination connection manager while configuring the OLEDB destination component. This may well be a

package-level connection manager (with the .conmgr extension) in SQL Server 2012.



CHAPTER 1 ■ Sourcing Data from MS Office Applications

As you have probably seen, SSIS names the source component with the full path and file name, followed by

the username. You may prefer to rename this to something more palatable. Should you need to alter any aspect

of the source connection manager, just double-click it in the lower pane, and edit the connection manager.

For a package-level connection manager, you have to edit it in the Connection Managers folder of the Solution

Explorer window. Finally, it can be worth clicking the Test Connection button at step 10—if only to get early

warning of a connection problem.

Hints, Tips, and Traps

Yes, it is a real pain that you have to copy and paste (or worse, type in) the path and file

name of the Access source database when using the ACE driver.

In a real-world scenario, it is advisable to select SQL Command as the data access mode

in step 11, and enter or build a query in step 12 (using the aptly-named Build Query

button) to select only the columns that you need, as well as filtering out any unwanted

records, aliasing column names, converting data types, and so forth.

Should you be writing a query to select the source data, then note that you must use

T-SQL, not Access SQL.

Should you need to massage your data as it flows from source to destination, then myriad

techniques to do this are described in Chapter 9.

The 32-bitDTExec is found in C:\Program Files (x86)\Microsoft SQL Server\110\

DTS\Binn for SQL Server 2012. Replace 110 with 90 for SQL Server 2005, and with 100 for

SQL Server 2008.

Calling a 32-bit executable from SQL Server agent is easy; just check the check box on the

Job Step page to run the package in 32-bit mode.

1-15. Convert a Complex Access Database to SQL Server


You have a complex Access database that cannot be imported quickly or easily and which may potentially require

considerable repurposing and refactoring.


Use the SQL Server Migration Assistant for Access (SSMA).


Install SSMA (described in detail shortly).


Launch SSMA from the Start menu.


Click Close to exit the Migration Wizard. The four empty panes of the SSMA interface



Click File ➤ New Project (or the button on the toolbar), enter the project’s name, and

enter or browse for a directory where the project (and all the metadata for the source

and destination objects) will be stored. Choose a destination SQL Server database

version (this even works with SQL Server Azure). The dialog box looks like Figure 1-25.



CHAPTER 1 ■ Sourcing Data from MS Office Applications

Figure 1-25.  Creating a new SSMA project


Click OK.


Click File ➤ Add Databases (or the toolbar button), and select the Access database(s)

you wish to migrate. Repeat this step for each database to add. The database(s)

appear in the top-left pane, Access Metadata Explorer.


Expand the databases and select the table(s) you wish to migrate. The table structure

appears in the top-right pane, something like Figure 1-26.

Figure 1-26.  Source metadata in SSMA


Click File ➤ Connect to SQL Server (or the button in thetoolbar) and enter the details

of the server to connect to, and then click OK. The list of all the available databases on

the destination server appear in the bottom left pane, SQL Server Metadata Explorer.


Expand the destination database, and select the destination schema (see Figure 1-27).



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

1-14. Importing Access Data as Part of a Regular ETL Process

Tải bản đầy đủ ngay(0 tr)