Advanced Queries and Linked Servers

Advanced Queries and Linked Servers Advanced Queries and Linked Servers Objectives Create dynamic SQL in stored procedures. Use SQL Server cursors. Learn how to partition data horizontally. Create partitioned views to access partitioned data. Create distributed partitioned views to access data on multiple servers. Learn about SQL Server s distributed query architecture. Use linked servers to access heterogeneous data. Use OPENROWSET to create ad hoc queries against remote data. Use OPENQUERY to create pass-through queries. Microsoft SQL Server 2000 Professional Skills Development 13-1

Advanced Queries and Linked Servers Dynamic SQL With the introduction of user-defined functions in SQL Server 2000, the need to build a dynamic SQL statement inside of a stored procedure has diminished. A user can simply select columns from an inline or table function to create their own dynamic SQL statements, or a scalar function can return a string consisting of a dynamic SQL statement. However, you can still write a stored procedure that can take any number of parameters and select the data based only on the criteria supplied. The technique involves creating a stored procedure with input parameters for every possible search criteria. Each input parameter is then tested to see if a value was supplied, and a dynamic SQL statement is built using only those parameter values. Stored Procedure with Dynamic WHERE Clause See AdvancedQueries.SQL The following example, procemployeesearchdynamic, has optional input parameters for every possible field used in the WHERE clause. If a parameter is supplied, then it will be used in the WHERE clause. If no parameters are supplied, then the WHERE clause will be omitted, and all of the columns and rows will be returned. This makes the stored procedure very flexible no matter what is tossed to it in the way of parameters, a result set will be returned. Here s the declaration of the stored procedure with the input parameters along with some variables to build up the dynamic SQL string and WHERE clause: CREATE PROCEDURE procemployeesearchdynamic @LastName varchar(50) = NULL, @FirstName varchar(20) = NULL, @Email varchar(50) = NULL, @City varchar(25) = NULL, @State varchar(2) = NULL AS DECLARE @SQL nvarchar(2000) DECLARE @vcwhere nvarchar(1000) DECLARE @vcselect nvarchar(1000) 13-2 Microsoft SQL Server 2000 Professional Skills Development

Dynamic SQL If no parameters are supplied, then the SELECT statement is executed without a WHERE clause and the stored procedure ends with the RETURN statement: IF (@LastName IS NULL AND @FirstName IS NULL AND @Email IS NULL AND @City IS NULL AND @State IS NULL) BEGIN PRINT 'Selecting All Employees ' SELECT EmployeeID, LastName, FirstName, url_emailaddress, City, State, ZipCode, HomePhone FROM tblemployee RETURN END If at least one input parameter was supplied, then build up the dynamic SQL statement and the WHERE clause: SELECT @vcselect='select EmployeeID, LastName, FirstName, url_emailaddress, City, State, ZipCode, HomePhone FROM Shark.dbo.tblEmployee WHERE' -- Initialize variable to empty string SELECT @vcwhere='' -- Single quotes are required to delimit -- string data. IF NOT @LastName IS NULL SELECT @vcwhere=@vcwhere + ' AND LastName=''' + @LastName + '''' Microsoft SQL Server 2000 Professional Skills Development 13-3

Advanced Queries and Linked Servers IF NOT @FirstName IS NULL SELECT @vcwhere=@vcwhere + ' AND FirstName=''' + @FirstName + '''' IF NOT @Email IS NULL SELECT @vcwhere=@vcwhere + ' AND url_emailaddress=''' + @Email + '''' IF NOT @City IS NULL SELECT @vcwhere=@vcwhere + ' AND City=''' + @City + '''' IF NOT @State IS NULL SELECT @vcwhere=@vcwhere + ' AND State=''' + @State + '''' Once the string for the WHERE clause is constructed, there will be an extra AND on the front of it that needs to be stripped off: SELECT @vcwhere=right(@vcwhere,len(@vcwhere)-4) The SELECT statement then gets concatenated with the WHERE clause: SELECT @SQL=@vcSelect + @vcwhere -- This is for debugging purposes PRINT @SQL Then the sp_executesql stored procedure is called, which caches a query plan for the execution of the stored procedure. EXEC sp_executesql @SQL 13-4 Microsoft SQL Server 2000 Professional Skills Development

Dynamic SQL When you execute the stored procedure, you ll get different result sets, depending on how many input parameters you supply. Figure 1 shows the result sets. EXEC procemployeesearchdynamic EXEC procemployeesearchdynamic @State='WA' EXEC procemployeesearchdynamic @LastName='Peters',@State='WA' Figure 1. The result sets from executing the stored procedure with three different sets of parameters supplied. EXECUTE, EXECUTE(), and sp_executesql The EXECUTE statement, EXECUTE() function, and sp_executesql stored procedure all execute things, but there are differences in the way each one is used. EXECUTE The EXECUTE, or EXEC statement is used to execute a stored procedure by following the command with the name of the stored procedure and any appropriate parameter arguments: EXEC procemployeesearchdynamic @State='WA' EXECUTE() The EXECUTE(character_string) function is different it executes a character string that contains a Transact-SQL command. You can shorten the Microsoft SQL Server 2000 Professional Skills Development 13-5

Advanced Queries and Linked Servers name of the function to EXEC(character_string), and the character string argument can be as long as 8 KB. The EXEC() function is not compiled until run time and the plan generated is not cached and reused. The following example executes a dynamic string that concatenates literal strings with variable values: DECLARE @col varchar(20) DECLARE @table varchar(20) SELECT @col = 'LastName' SELECT @table = 'tblemployee' EXEC('SELECT ' + @col + ' FROM ' + @table) sp_executesql The sp_executesql stored procedure also executes a character string, passed in as an input parameter, but unlike EXEC(), sp_executesql generates an execution plan that gets cached and reused if the same string is executed again. Also, sp_executesql must be passed a Unicode string. If you use a variable to build the string to be executed, use the nvarchar data type in the declaration and preface any literal strings with N. The following example will cache an execution plan for the SELECT statement as long as you use the three-part naming convention for the table: DECLARE @SQL nvarchar(100) SELECT @SQL = N'SELECT * FROM Shark.dbo.tblCategory' EXEC sp_executesql @SQL The main difference in the syntax required between the EXEC() and sp_executesql is that EXEC() will allow you to concatenate literals and variables to build up a string expression, while sp_executesql requires a string constant or a single string variable. Dynamic SQL and Permissions One issue that limits the use of dynamic stored procedures is the issue of permissions required to execute the SQL statement that has been constructed. Normally, a user is not required to have any permissions on the underlying tables the EXECUTE permission granted to them on the stored procedure is sufficient as long as the stored procedure and underlying tables have the same owner. When the tables referenced by the stored procedure and the stored procedure have the same owner, then SQL Server doesn t check the user s 13-6 Microsoft SQL Server 2000 Professional Skills Development

Dynamic SQL permissions on the tables. This allows users to work with data only through stored procedures. However, if the stored procedure builds up a dynamic string which is then executed using EXEC() or sp_executesql, then the user must be granted the necessary permissions on the underlying tables, or the query will fail. When SQL statements are executed dynamically inside of a stored procedure, the permissions required on the underlying tables are the same as if the SQL statement was being executed outside of the stored procedure. Unless you re willing to grant users SELECT permissions on the underlying tables, then user-defined functions are probably a better choice for creating dynamic queries. Microsoft SQL Server 2000 Professional Skills Development 13-7

Advanced Queries and Linked Servers Transact-SQL Cursors If you have worked with Visual Basic or Active Server Pages, you ve probably used DAO or ADO recordsets. A Transact-SQL cursor works just like a recordset by allowing you to navigate through and manipulate individual rows in a result set. Cursors use a different syntax from recordsets, so they can be confusing at first. But the underlying concepts are the same, and you use cursors for many of the same reasons you use recordsets. Cursors are expensive they should be used only when there is no alternative. SQL Server is a relational database, and working with relational sets rather than with individual rows is always going to give you better performance. A cursor allows you to iterate through the results of a select statement and to take different actions for each row, based on the values of the data. Although cursors are expensive to work with, you can reduce the cost by using the least amount of scrolling and locking forward-only, read-only cursors perform the best. When to Use Cursors The easiest answer for when to use cursors is never, and this isn t just a silly answer. In most cases you could use temp tables or some other technique for accomplishing the same result. But you may well need to work on a project where someone else has used cursors, and occasionally you ll come upon a problem for which a cursor may be the best solution. You should consider using a cursor anytime you need to perform some sort of processing on each row of a result set individually. For example, you may need to perform a complex financial computation using the data in each row. If your calculation can be expressed in a single Transact-SQL expression, then no cursor is required you can simply create a column based on that expression. However, if your calculation requires several lines of Transact-SQL, perhaps using loops and conditional logic, then you really need to process the data one row at a time. You could do this in a client application, using a recordset, or you could do it in a stored procedure on the server using a cursor. How to Use Cursors Here are the steps you need to follow in your Transact-SQL code to use a cursor for working with individual rows in a result set: Step 1: Declare the cursor. When a cursor is declared, it must not only be given a name, but also a type and scrolling method. In addition, you specify whether the cursor will be local used only in that stored procedure, or global able to be shared by several procedures. Since the data in the 13-8 Microsoft SQL Server 2000 Professional Skills Development

Transact-SQL Cursors following example is not going to be modified, the best choice is a fast_forward cursor type, which gives you a forward-scrolling, read-only cursor. Step 2: Open the cursor. Step 3: Fetch the first row and return its data into a set of variables separated by commas. The variables must be listed in the same order as the fields in the result set. In the procbuildselect example listed below, only one column is returned, so only one variable is used, @Name. Step 4: Setup a loop using the WHILE command, and check the results of each FETCH operation using @@FETCH_STATUS. The Fetch status codes are detailed in Table 1. Code Definition 0 Success -1 Fetch has moved beyond the end of results (EOF) -2 Row is missing (it has been altered or deleted) Table 1. Fetch status codes. Step 5: Fetch the remaining rows, one by one, until reaching the end of the cursor. Step 6: Close and deallocate the cursor. This will release any locks and any memory that the cursor may have used. A Cursor Example This example illustrates another circumstance where a cursor may be appropriate. The example builds a stored procedure that allows you to feed it the name of a table and get back a string containing a SELECT statement that explicitly names each of the columns in the table. The names of the columns for every table are stored in a system table, syscolumns. The syscolumns table has one row for each column in the database, with an id field that identifies the table and a name field with the name of the column (plus fields for many other attributes of each column). So, to gather up the names of every column in a table, you need to visit multiple rows from syscolumns, building a SELECT statement with columns that match a particular table ID. Microsoft SQL Server 2000 Professional Skills Development 13-9

Advanced Queries and Linked Servers The following procedure takes the name of a table as an input parameter and opens a cursor that includes one row from syscolumns for every column in the specified table. As the code moves through the rows of the cursor, the column names are concatenated into a SELECT statement that is returned as an output parameter: CREATE PROCEDURE procbuildselect @TableName varchar(130), @SQL varchar(8000) OUTPUT AS BEGIN DECLARE @OID int DECLARE @Name varchar(130) -- Get the Object_id for the table SELECT @OID = object_id(@tablename) IF @OID IS NULL BEGIN -- Return the results in a column called SQL SELECT @SQL='Table Not Found' RETURN -- Bail out here END -- Start building string SELECT @SQL='SELECT ' -- Declare cursor DECLARE table_cursor CURSOR Local Fast_Forward FOR SELECT Name FROM syscolumns WHERE ID=@OID ORDER BY colid -- Open cursor OPEN table_cursor -- Fetch first row FETCH NEXT FROM table_cursor INTO @Name 13-10 Microsoft SQL Server 2000 Professional Skills Development

Transact-SQL Cursors -- Loop through remaining rows WHILE @@FETCH_STATUS=0 -- Loop until no more data can be found BEGIN IF not @@FETCH_STATUS = -2 BEGIN Select @SQL=@SQL + @Name + ', ' END FETCH NEXT FROM table_cursor INTO @Name END -- Close and deallocate cursor CLOSE table_cursor DEALLOCATE table_cursor -- Now remove the extra comma and space off the end SELECT @SQL=substring(@SQL, 1, Datalength(@SQL)-2) -- And add the FROM clause SELECT @SQL=@SQL + ' FROM ' + @TableName END Executing the stored procedure against the tblcategory table will return a string containing a fully-qualified (all columns named) SELECT statement. You can test the stored procedure and then execute the returned SELECT statement like this: DECLARE @SQL varchar(4000) EXEC procbuildselect 'tblcategory', @SQL OUTPUT -- Show the resulting SELECT statement PRINT @SQL -- Execute the returned SELECT statement EXECUTE(@SQL) Microsoft SQL Server 2000 Professional Skills Development 13-11

Advanced Queries and Linked Servers Handling Large Data Sets Working with large tables can be challenging, particularly if you have a database that is being used for data entry as well as decision support. In this section you ll learn how to partition data, breaking it up into separate tables, and creating partitioned views to join it back together again. Horizontally Partitioning Tables When a single table becomes too large to work with efficiently, it can be horizontally partitioned by being broken into separate tables. Each table has an identical schema, but each contains a separate and distinct range of data. For example, you could split a table on an ID column value, where values 10,000 to 20,000 are stored in one partition, values 20,001 to 30,000 are stored in another partition, and so on. Each partition has the same number of columns, but fewer rows than the original table. You can also partition on other column values, such as date ranges, regions, or other industry-specific codes. Each table must have a CHECK constraint enforcing the range of values so that there is no overlap between tables. If you wanted to partition your enormous Sales table, here s an example of the script you d use to create a simple table named tblsales1 with an ID value range starting at 10,000: CREATE TABLE dbo.tblsales1 (ID int NOT NULL IDENTITY (10000, 1), SalesData money NOT NULL) ON [PRIMARY] GO 13-12 Microsoft SQL Server 2000 Professional Skills Development

Handling Large Data Sets You d then create tblsales2 with an IDENTITY seed of 20,001, and tblsales3 with an IDENTITY seed of 30,001: CREATE TABLE dbo.tblsales2 (ID int NOT NULL IDENTITY (20001, 1), SalesData money NOT NULL) ON [PRIMARY] GO CREATE TABLE dbo.tblsales3 (ID int NOT NULL IDENTITY (30001, 1), SalesData money NOT NULL) ON [PRIMARY] GO After creating each of the tables, you need to create a CHECK constraint that strictly limits the values that can be inserted into the ID column. Here s the CHECK constraint for tblsales1, tblsales2, and tblsales3: ALTER TABLE dbo.tblsales1 ADD CONSTRAINT CK_tblSales1 CHECK (ID BETWEEN 10001 AND 20000) ALTER TABLE dbo.tblsales2 ADD CONSTRAINT CK_tblSales2 CHECK (ID BETWEEN 20001 AND 30000) ALTER TABLE dbo.tblsales3 ADD CONSTRAINT CK_tblSales3 CHECK (ID BETWEEN 30001 AND 40000) Once you ve partitioned the table and it s now many separate tables, you need an efficient way to query all of the separate tables. This is where a horizontally partitioned view comes in. You can query the view without having to worry about the fact that there are actually three separate tables involved. Use the UNION ALL operator to join the tables together in the view: Microsoft SQL Server 2000 Professional Skills Development 13-13

Advanced Queries and Linked Servers CREATE VIEW vwsalesunionall AS SELECT * FROM dbo.tblsales1 UNION ALL SELECT * FROM dbo.tblsales2 UNION ALL SELECT * FROM dbo.tblsales3 TIP: Always use UNION ALL over a plain UNION statement even when you know there are no duplicate records. If you omit the ALL keyword, SQL Server will take another pass through the query to eliminate any duplicates, slowing down performance. The beauty of using a partitioned view is that SQL Server won t waste time looking through all the tables to fulfill a query that works with a specific range of data that falls within the values limited by the CHECK constraint. The SQL Server engine will quickly examine all the tables that comprise the view and determine which tables have the required data through the check constraints. The engine will then query the appropriate table without attempting to select any records from the other tables that form part of the union. The following SELECT statement from vwsalesunionall will cause SQL Server to look only in the tblsales2 table because the WHERE clause values fall within the CHECK constraint defined for tblsales2: SELECT * FROM vwsalesunionall WHERE ID BETWEEN 21000 AND 25000 Partitioning increases performance by using less I/O to find and retrieve the requested data. Later in this chapter you ll learn about distributed partitioned views, where data can be partitioned across multiple servers. Partitioned views are updatable as long as they meet the following conditions: The view definition comprises a series of SELECT statements whose individual result sets are combined using the UNION ALL operator. Each single SELECT statement references a single SQL Server base table. The table can be either a local table, or a remote table. In addition, partitioned views can also be updated with INSTEAD OF triggers. 13-14 Microsoft SQL Server 2000 Professional Skills Development

Handling Large Data Sets Distributed Partitioned Views Distributed partitioned views allow you to access tables that have not only been partitioned, but are also located on remote servers. A distributed partitioned view allows you to retrieve data from each data source, presenting it as though it came from a single table on a single server. The implementation of distributed partitioned views in SQL Server is designed for high-end OLTP (Online Transaction Processing) and Web site databases with individual SQL statements retrieving minimal data from enormous tables. Distributed partitioned views give you an edge when you have large tables partitioned on multiple servers. Queries accessing only a fraction of the data can run faster because there s less data to scan. If the tables are located on different servers or on a computer with multiple processors, each table involved in the query can also be scanned in parallel, thereby improving query performance. Additionally, maintenance tasks, such as rebuilding indexes or backing up a table, can execute more quickly. By using a partitioned view, the data still appears as a single table and can be queried as such without having to reference the correct underlying table manually. Here are the steps for setting up distributed partitioned views: 1. Add each member server as a linked server. The view needs direct access to data located on all of the other servers. All tables must have the same format, the same number of columns, and the columns must have the same attributes. The range of values must be enforced by a CHECK constraint, and the ranges can t overlap. 2. Create multiple databases, each on a different member server running an instance of SQL Server. 3. Use the sp_serveroption system stored procedure on each server to set the lazy schema validation option. What this does is prevent the query processor from requesting meta data for the linked tables until it actually needs the data, thus boosting performance. 4. Create a partitioned view using the UNION ALL operator on each server, using the same name for each one. This allows queries referencing the distributed partitioned view name to run on any of the member servers. When designing the partitions, try to partition the data so that related data is placed together on a member server. In addition, a partition should allow all rows to be placed on the same server as all of their referenced foreign key rows. In other words, you don t want to be doing cross-server joins. The partition should be defined on a column that most evenly distributes the data among the partitioned tables. This depends on your data in some cases, the primary key may be suitable, or perhaps a region or date. Microsoft SQL Server 2000 Professional Skills Development 13-15

Advanced Queries and Linked Servers Here s how you d rewrite the view used in the previous example if it were a distributed partitioned view: CREATE VIEW vwsalesdistributed AS SELECT * FROM ThisDatabase.dbo.tblSales1 UNION ALL SELECT * FROM LinkedServer2.Database2.dbo.tblSales2 UNION ALL SELECT * FROM LinkedServer3.Database3.dbo.tblSales3 Each of the linked servers needs its own copy of the distributed partitioned view that references the other servers. You d create a version of vwsalesdistributed on LinkedServer2 and LinkedServer3 that are customized to those servers, so that all of the servers talk to each other. Setting up linked servers is covered later in this chapter. TIP: Distributed partitioned views are not updatable. Use an INSTEAD OF trigger when you need to perform updates to a table through a distributed partitioned view. Distributed partitioned views allow you to scale out your database in a very transparent way. To a user selecting data from the view, it appears as though the data is being fetched from a single table in a single database on a single server. Distributed partitioned views can also be used to implement a federation of database servers. Each server is administered independently, but they cooperate to share the processing load. This allows you to scale out a set of servers to support the processing requirements of extremely large and/or hightransaction-rate databases. See the Books Online topic, Designing Federated Database Servers for more information. Vertically Partitioning Tables Vertical partitioning divides a single table into multiple tables based on selected columns rather than by values. This is useful when large data fields known as BLOBs (binary large objects) are required, but not constantly used. BLOBs in SQL Server consist of data stored in text, ntext, or image data types. If you have image data stored in a database, it can be partitioned vertically by creating a separate table so that it is not retrieved except when needed. 13-16 Microsoft SQL Server 2000 Professional Skills Development

Handling Large Data Sets For example, if you have an image consisting of the bitmap rendering of an ID photo for an employee, it can be located in a separate table linked back to the Employee table in a one-to-one relationship on the EmployeeID, as shown in Figure 2. Figure 2. Image data can be vertically partitioned by locating it in a separate table. By partitioning the image into a separate table, storage space requirements are reduced in the tblemployee table. Queries that select all columns (*) from tblemployees will no longer pull down the image data. Text in Row Text in row is a new feature in SQL Server 2000 that improves the speed with which small-to-medium size text, ntext, or image column data can be retrieved. Normally, only pointers are stored in the row. These pointers point to the root node of a tree built of internal pointers that map to the data pages in which string fragments of the BLOBs are actually stored. However, if the text or image data is small enough, you can enable the text in row property of the table to allow the data to be stored in the row itself, instead of storing the pointers. This makes reading the contents of these columns as fast as reading or writing character and binary strings because SQL Server does not have to access separate pages to read or write the BLOB string. There must be sufficient room left in the row to hold the data the maximum row size in SQL Server 2000 is 8 KB, and the maximum size allowed for the text, ntext, or image data is 7,000 bytes, or 7 KB. There are two ways to enable text in row, and each uses the sp_tableoption stored procedure: sp_tableoption N'tblEmployeePhoto', 'text in row', 'ON' Microsoft SQL Server 2000 Professional Skills Development 13-17

Advanced Queries and Linked Servers This will turn on text in row, but the limit in size for the photo would be 256 bytes. To enable a larger image, specify the bytes instead of using ON. The following example will set the maximum size to the limit of 7,000 bytes. sp_tableoption N'tblEmployeePhoto', 'text in row', '7000' If the image being stored is larger than 7 KB, then it will not be stored in the row, pointers will be stored instead. 13-18 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries Distributed Queries Distributed queries in SQL Server allow you to access data stored on multiple computers that are running SQL Server or to access heterogeneous data sources. These heterogeneous data sources can be either relational or nonrelational for which either an OLE DB provider or ODBC driver exists. In other words, you can get at your Oracle data, your Access data, or data stored in a text file that you normally access in Notepad. This data appears as though it was just another SQL Server table. SQL Server can be used as a gateway to all other database platforms and vendors within your enterprise. The Distributed Architecture Prior to SQL Server 7.0, client applications that needed to reference data on multiple platforms (or multiple servers), were required to purchase client access licenses for each platform and to distribute all of the necessary ODBC libraries and communications component to every client application that used them. Each client application then was required to have its own connection to the data source. Figure 3 shows what that architecture looked like. Figure 3. Client requirements without using distributed queries. With the introduction of SQL Server 7.0, the distributed architecture was implemented with the concept of linked servers, which is illustrated in Figure 4. The only client requirement is that the OLE DB provider for SQL Server be installed. All other components and protocols needed can be installed on the Microsoft SQL Server 2000 Professional Skills Development 13-19

Advanced Queries and Linked Servers SQL Server machine, with SQL Server providing the gateway to diverse data sources. Figure 4. Using SQL Server as a gateway for distributed queries. There are two ways to take advantage of this architecture: Ad hoc queries. You can use the OPENROWSET or OPENQUERY functions (discussed later in this chapter) to query remote data. This is generally used when the query is a one-time-only occasion. Linked servers. You can set up a linked server, which registers the server so that SQL Server knows where to look for the remote data and objects. This is useful when you repeatedly query remote data because the link is already configured. The next section covers setting up linked servers. Setting Up Linked Servers You can use either the Enterprise Manager or system stored procedures to configure a linked server. Try It Out! Follow these steps to set up a linked server to the Microsoft Access Northwind.mdb data base using the Enterprise Manager: 1. From the registered server, expand the Security node. 13-20 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries 2. Right-click on Linked Servers. 3. Select New Linked Server from the menu. This loads the Linked Server Properties dialog box shown in Figure 5. Figure 5. Creating a linked server to the Northwind database. 4. Type a name that you will use when you query the linked server in the Linked server text box. Select the Microsoft Jet 4.0 OLE DB Provider, and in the Data Source, type in the path and filename where Northwind.mdb can be found. It s usually located in the \Program Files\Microsoft Office\Office\Samples directory if you ve done a full install of Office. 5. This is all of the information that s required filling in the other fields is optional for an Access database. Click OK when finished. The information you need to supply depends on the requirements of the OLE DB provider. The Access Northwind database does not have any security requirements, so you can ignore the Security tab. However, if you re linking to an Oracle database, you ll need to provide an appropriate login and password. Microsoft SQL Server 2000 Professional Skills Development 13-21

Advanced Queries and Linked Servers Using sp_addlinkedserver You can set up a linked server using the sp_addlinkedserver system stored procedure. Here s the syntax: sp_addlinkedserver [@server =] 'server' [, [@srvproduct =] 'product_name'] [, [@provider =] 'provider_name'] [, [@datasrc =] 'data_source'] [, [@location =] 'location'] [, [@provstr =] 'provider_string'] [, [@catalog =] 'catalog'] As you can see, the information provided in the parameters matches the information in the Linked Server dialog box displayed in the Enterprise Manager. Use this syntax to create a login to the Access Northwind database: sp_addlinkedserver @server = 'AccessNwind', @provider = 'Microsoft.Jet.OLEDB.4.0', @srvproduct = 'OLE DB Provider for Jet', @datasrc = 'D:\Programs\Northwind.mdb' If you re linking an unsecured Access database, you re done. However, if you are linking to a server that requires authentication, then you must use the sp_addlinkedsrvlogin stored procedure to add a login to be used. Here s the syntax: sp_addlinkedsrvlogin [@rmtsrvname =] 'rmtsrvname' [,[@useself =] 'useself'] [,[@locallogin =] 'locallogin'] [,[@rmtuser =] 'rmtuser'] [,[@rmtpassword =] 'rmtpassword'] 13-22 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries NOTE If you are running linked SQL Servers only, you can map login accounts and passwords between local and remote SQL Servers by using the sp_addlinkedsrvlogin system stored procedure. When you map a local account to a remote login account, you do not have to create a login account and password for each user on the remote SQL Server. If the Access database was secured, and you wanted to use the Admin user account with a password of password, then you d need to add the login: EXEC sp_addlinkedsrvlogin @rmtsrvname='accessnwind', @useself='false', @rmtuser='admin' @rmtpassword = 'password' Note that the login and password must already exist in the Access database. NOTE If you are working with a secured Access database, you must place the name and location of the workgroup file (the default is system.mdw) in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\ Engines\SystemDB Unfortunately, SQL Server does not allow for the fact that you might have multiple workgroup files or work with multiple secured Access databases. So the bottom line is that you can only link to Access databases that all use the same workgroup file. Microsoft SQL Server 2000 Professional Skills Development 13-23

Advanced Queries and Linked Servers Querying Linked Servers You can t do much with a linked server in the Enterprise Manager except view a list of the linked tables by expanding the Tables node, as shown in Figure 6 for the tables in the Access Northwind database. Figure 6. The tables in the Access Northwind database. However, that same list is also provided by the sp_tables_ex system stored procedure. A partial result set is shown in Figure 7. Note that sp_tables_ex displays all of the Access systems tables and does not filter any of them out. EXEC sp_tables_ex 'AccessNwind' Figure 7. Getting a list of tables in the linked server. 13-24 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries TIP: Other system stored procedures that return information about linked servers include sp_linkedservers, sp_catalogs, sp_indexes, sp_primarykeys, and sp_columns_ex. Selecting Data from a Linked Server The syntax you need to query a linked server is slightly different than syntax you use with normal SQL Server tables in that it requires a special four-part naming convention: LinkedServerName.Catalog.Schema.TableName As you can see from Figure 7, there are only NULLs listed in the TABLE_CAT and TABLE_SCHEM columns for an Access database, so you can omit the catalog and schema arguments and just type the three dots between the linked server name and the name of the table you re interested in. The following query will select the CategoryName and Description from the Northwind Categories table. The results are shown in Figure 8. SELECT CategoryName, Description FROM AccessNwind...Categories Figure 8. The result set from a linked server query. Microsoft SQL Server 2000 Professional Skills Development 13-25

Advanced Queries and Linked Servers You can work with linked tables as though they were local tables, as long as you adhere to the four-part naming convention. The following query joins the Northwind Category table to the Shark tblcategory on Category ID and lists categories with the same ID. The result set is shown in Figure 9. SELECT Linked.CategoryName, Local.Category FROM AccessNwind...Categories AS Linked INNER JOIN Shark.dbo.tblCategory AS Local ON Linked.CategoryID = Local.CategoryID Figure 9. The result set from the heterogeneous join between the Access Northwind and the SQL Server Shark categories tables. If linked server queries seem a little slow to you, it s probably because at least part of the query is being processed on the remote server. In the case of the above example, the Jet engine has to wake up and select all of the rows from the Categories table and pass them back to SQL Server so the rows can be joined to the tblcategory table. For that reason, queries executed on a linked server are known as pass-through queries. TIP: If you are running any kind of distributed queries from your client applications, make sure to set the SET ANSI_NULLS ON and SET ANSI_WARNINGS ON options prior to issuing the queries. These options are set to ON in the Query Analyzer by default, but that may not be the case with your client application. Ad Hoc Querying Ad hoc querying is useful when you do not expect to reuse the query later, and you don t want to go to the trouble of setting up a linked server. You can use the OPENROWSET function when you need to execute a query against a remote source only once. 13-26 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries OPENROWSET The OPENROWSET function lets you create an ad hoc query without having to set up a linked server. As you d expect, all of the connection information is required as part of the syntax for the OPENROWSET function: OPENROWSET('provider_name' {'datasource'; 'user_id'; 'password' 'provider_string'}, {[catalog.][schema.]object 'query'}) The following query uses OPENROWSET, passing in the connection information needed to connect to the Access Northwind database. Note that here you must supply a user ID and password (Admin with no password is used for an unsecured Access database). The OPENROWSET function executes the following pass-through query in Access, returning the result set to SQL Server. The result set is shown in Figure 10. SELECT Nwind.CategoryName FROM OPENROWSET('Microsoft.Jet.OLEDB.4.0', 'D:\Programs\Northwind.mdb'; 'Admin';'', 'SELECT CategoryName FROM Categories') AS Nwind Figure 10. Using OPENROWSET against the Access Northwind Categories table. OPENQUERY OPENQUERY differs from OPENROWSET in that it requires a linked server in order to operate. It is also much slower than OPENROWSET, so you wouldn t want to use it in preference to querying the linked server directly, using the Transact-SQL four-part naming syntax. The advantage of Microsoft SQL Server 2000 Professional Skills Development 13-27

Advanced Queries and Linked Servers OPENQUERY is that it allows you to create pass-through queries using provider-specific syntax. In other words, your query uses whatever dialect of SQL the provider uses. Here s the syntax for OPENQUERY: OPENQUERY (LinkedServerName, query) The following example executes an Access cross-tab query, the syntax of which is completely illegal in Transact-SQL. In addition, the query also uses Access-specific functions like DatePart. The result set is shown in Figure 11. SELECT * FROM OPENQUERY( AccessNwind, 'TRANSFORM Sum(CCur([Order Details].[UnitPrice]*[Quantity]* (1-[Discount])/100)*100) AS ProductAmount SELECT Products.ProductName FROM Products INNER JOIN (Orders INNER JOIN [Order Details] ON Orders.OrderID = [Order Details].OrderID) ON Products.ProductID = [Order Details].ProductID WHERE (((Orders.OrderDate) Between #1/1/1997# And #12/31/1997#)) GROUP BY Products.ProductName PIVOT "Qtr " & DatePart("q",[OrderDate],1,0) In ("Qtr 1","Qtr 2","Qtr 3","Qtr 4");' ) Figure 11. The result set from an Access pass-through query using OPENQUERY. OPENQUERY allows you to use provider-specific syntax that SQL Server simply couldn t process. This is useful for querying data from an OLAP cube 13-28 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries or other data sources such as Microsoft Index Server, where the syntax used has no relationship to Transact-SQL whatsoever. OPENQUERY allows you to query the data source using its native syntax, but returns the result set in such a way that SQL Server can present it to the client as though it were native SQL Server data. Microsoft SQL Server 2000 Professional Skills Development 13-29

Advanced Queries and Linked Servers Summary Create dynamic SQL in stored procedures using the EXEC() or sp_executesql methods. SQL Server cursors can be used like client-side recordsets when you need to iterate through data a row at a time. Partitioning data horizontally gives a performance boost to larger tables. Partitioned views can access partitioned data as though it were in one table. Distributed partitioned views allow access to partitioned data on multiple servers. Data can be partitioned vertically to allow efficient storage of BLOB (text, ntext, and image) data. BLOBs can be stored in normal table rows by setting the text in row option in a table. SQL Server s distributed query architecture allows you to use SQL Server as a gateway to many different data sources. Linked servers set up a permanent connection to multiple data sources. The OPENROWSET function allows you to create ad hoc queries against remote data. The OPENQUERY function allows you to create pass-through queries using the provider s native syntax. 13-30 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries Questions 1. Does a user need permissions on the underlying tables when issuing a dynamic query inside of a stored procedure using EXECUTE() or sp_executesql? 2. When should you choose to use a cursor over using Transact-SQL statements? 3. How does a partitioned view know in which table a range of data is located? 4. What does the text in row setting do? 5. Name two ways to set up a linked server. 6. What is the difference between OPENROWSET and OPENQUERY? Microsoft SQL Server 2000 Professional Skills Development 13-31

Advanced Queries and Linked Servers Answers 1. Does a user need permissions on the underlying tables when issuing a dynamic query inside of a stored procedure using EXECUTE() or sp_executesql? Yes. Even if the user has EXECUTE permissions on the stored procedure, they still need SELECT on the underlying tables since the string is being processed separately. 2. When should you choose to use a cursor over using Transact-SQL statements? If there s another way to do something, then never. Choose to use cursors only when there s no other way to accomplish a particular programming task. 3. How does a partitioned view know in which table a range of data is located? By the CHECK constraint created in the underlying tables that used to enforce the range of data in the table. 4. What does the text in row setting do? Allows you to store small-to-medium size text, ntext, or image data in a data row. 5. Name two ways to set up a linked server. Use the Enterprise Manager by going into the Linked Servers Node, or by running the sp_addlinkedserver system stored procedure. 6. What is the difference between OPENROWSET and OPENQUERY? OPENQUERY requires a linked server and OPENROWSET does not. OPENQUERY allows you to use the syntax of the provider, whereas OPENROWSET uses Transact-SQL. 13-32 Microsoft SQL Server 2000 Professional Skills Development

Distributed Queries Lab 13: Advanced Queries and Linked Servers TIP: Because this lab includes a great deal of typed code, we ve tried to make it simpler for you. You ll find all the code in AdvancedQueriesLab.SQL, in the same directory as the sample project. To avoid typing the code, you can cut/paste it from the text file instead. Microsoft SQL Server 2000 Professional Skills Development 13-33

Lab 13: Advanced Queries and Linked Servers Lab 13 Overview In this lab you ll learn how to set up a linked server to the Access Northwind.mdb database. You ll learn how to find out what tables and columns are available on the linked server, and build a query against it. To complete this lab, you ll need to work through two exercises: Setting Up a Linked Server Remote Querying Each exercise includes an Objective section that describes the purpose of the exercise. You are encouraged to try to complete the exercise from the information given in the Objective section. If you require more information to complete the exercise, the Objective section is followed by detailed step-bystep instructions. 13-34 Microsoft SQL Server 2000 Professional Skills Development

Setting Up a Linked Server Setting Up a Linked Server Objective In this exercise, you ll create a linked server to the Northwind.mdb Access database using the Enterprise Manager. You ll then use the sp_tables_ex stored procedure to find out what tables are available for querying. Things to Consider Where is the Northwind.mdb Access database located on your computer? You ll need to search for it in Windows Explorer before setting up the link. How do you set up a linked server using the Enterprise Manager? Which pieces of information are required to set up a linked Access server? How do you run the sp_tables_ex stored procedure? Step-by-Step Instructions 1. Right-click the Security Linked Servers node in the Enterprise Manager and select New Linked Server from the menu. 2. This loads the Linked Server Properties dialog box. Type the name NorthwindLink for the linked server name. Select the Microsoft Jet 4.0 OLE DB Provider from the drop-down listbox. Type in the location of the Northwind.mdb database on your machine. The location and filename would be the following string if Office was installed on your C:\ drive: C:\Program Files\Microsoft Office\Office\Samples\Northwind.mdb Microsoft SQL Server 2000 Professional Skills Development 13-35

Lab 13: Advanced Queries and Linked Servers 3. The completed dialog box should look like that shown in Figure 12. Click OK when finished. Figure 12. Setting up the NorthwindLink linked server. 4. To find out which tables are available, open the Query Analyzer and type in the following statement: EXEC sp_tables_ex 'NorthwindLink' 5. Execute the statement by pressing the F5 key. This will give you a list of tables that you can query in the Northwind.mdb database, as shown in Figure 13. Figure 13. The list of tables in the NorthwindLink linked server. 13-36 Microsoft SQL Server 2000 Professional Skills Development

Remote Querying Remote Querying Objective In this exercise, you ll create a SELECT query based on the Product Sales for 1997 view in the NorthwindLink linked server. You ll then create aggregate queries to sum the output, grouping by category and by quarter. Things to Consider What is the syntax used when selecting data from a linked server? How do you deal with names that have spaces in them? How do you create an aggregate query on linked server data? Step-by-Step Instructions 1. Create the following query in the Query Analyzer: SELECT * FROM NorthwindLink...[Product Sales for 1997] 2. Execute the query by pressing the F5 key. The output should look like that shown in Figure 14. Figure 14. The output from the Product Sales for 1997 query. Microsoft SQL Server 2000 Professional Skills Development 13-37

Lab 13: Advanced Queries and Linked Servers 3. To summarize product sales by category, write the following query: SELECT CategoryName, SUM(ProductSales) AS Total FROM NorthwindLink...[Product Sales for 1997] GROUP BY CategoryName 4. Run the query by pressing the F5 key. The result set is shown in Figure 15. Figure 15. Summarizing the Product Sales for 1997 by category. 5. To summarize by quarter, type the following query: SELECT ShippedQuarter AS Quarter, SUM(ProductSales) AS Total FROM NorthwindLink...[Product Sales for 1997] GROUP BY ShippedQuarter 6. Press F5 to execute the query. The result set is shown in Figure 16. Figure 16. Summarizing the Product Sales for 1997 by quarter. 13-38 Microsoft SQL Server 2000 Professional Skills Development