Работа с распределенными запросами

Tsql теория > Работа с распределенными запросами
26.02.2013 10:54:11



Статья:

Данные редко находятся в одном месте. В современном мире большинство новых проектов подключается к существующим источникам данных или, по крайней мере, расширяется за счет них. Вообще-то, это не является проблемы. SQL Server позволяет считывать данные из множества разных источников и записывать их туда. Гетерогенные объединения даже позволяют объединять данные SQL Server и электронных таблиц Excel.

SQL Server предлагает несколько различных методов доступа к внешним по отношению к текущей базе данным. От простой ссылки на другую локальную базу данных до выполнения сквозных запросов, которые задействуют другую базу данных с архитектурой “клиент/сервер’', — все это позволяет осуществить SQL Server.

Несмотря на то что SQL Server решает технические проблемы запросов к внешним данным, если две системы на самом деле обслуживаются разными приложениями, то прямое обращение к внешнему хранилищу данных в большинстве случаев нарушает принцип инкапсуляции. Таким образом, одновременное использование двух источников данных снижает гибкость архитектуры. Во многих программистских фирмах эта технология не находит поддержки. Вместо этого обмен данными осуществляется с помощью XML, SOAP и SOA

Связывание — это одностороннее конфигурирование (рис. 15.1). Если сервер А подключается к серверу Б, то это значит, что первый из них знает, как получить доступ к второму. Все время, пока сервер Б является доступным, сервер А для него является обычным пользователем.

Если связывание серверов является для вас новой концепцией, вы можете легко ее перепутать с регистрацией серверов в Management Studio. Как показано на рис. 15.1, Management Studio связывается с серверами как обычное клиентское приложение. В противоположность этому связывание серверов позволяет серверу А напрямую обращаться к серверу Б.

Связи могут быть установлены как в утилите Management Studio, так и в коде Т-SQL. Последний метод имеет преимущество возможности повторения подключения, если соединение будет неожиданно разорвано. В то же время создание подключения в коде Т-SQL требует большей работы.

Связываемый сервер может быть экземпляром SQL Server, либо другим источником данных с провайдером OLE DB, либо с драйвером ODBC. Распределенные запросы могут как извлекать данные, так и изменять их с помощью инструкций INSERT, UPDATE и DELETE (разумеется, в соответствии с требованиями провайдера OLE DB или драйвера ODBC).

Запросы SQL Server могут ссылаться на внешние данные с помощью обращения к предварительно сконфигурированному и подключенному серверу или определять подключение в самом коде запроса.

В этой главе будем называть рассматриваемые источники данных локальным и На заметку внешним. В других документах вы можете встретить такие определения, как локальный и удаленный, а также отправляющий и принимающий.

В некотором смысле подключение к внешнему источнику данных всего лишь перемещает объявление связи от кода запроса к заданию администрирования сервера. Так как запросы могут обращаться к именованным связям, не зная о реальном местонахождении сервера и регистрационных данных, запросы, использующие подключенные серверы, более портативные и легкие в обслуживании, чем те, которые определяют подключение в коде запроса. Если база данных перемещается на новый сервер, то, как только администратор создаст соответствующее подключение, запросы будут работать без какого-либо видоизменения.

В случае распределенного запроса SQL Server является клиентским процессом, получающим результаты от внешнего источника данных. Распределенные запросы могут либо извлекать данные в SQL Server для обработки, либо передавать запрос внешнему источнику данных.

Дополнительная Существует множество способов распределения данных. Вы можете использо-информация    вать репликацию (подробнее об этом — в главе 39) либо настраивать отдель

ный компьютер как сервер отчетности

Доступ к базе данных локального сервера

Когда осуществляется доступ к другой базе данных того же сервера, данные обрабатывает одно и то же ядро SQL Server. Таким образом, несмотря на то, что данные находятся вне текущей базы данных, запрос на самом деле не является распределенным.

Запрос SQL Server может осуществлять доступ к другой базе данных на том же сервере, обращаясь к таблице с использованием имени базы данных:

База_данных. Схема . Имя_Объекта

Поскольку база данных находится на том же сервере, его имя использовать не обязательно. Имя схемы может быть заменено именем владельца объекта. Обычно таблицы принадлежат владельцу схемы (dbo). Если это на самом деле так, то часть dbo можно опустить:

USE СНА2;

SELECT LastName, FirstName FROM OBXKit e s.dbo.Cont act;

Подключение с помощью T-SQL

Утилита Management Studio обрабатывает информацию о подключении и регистрационной записи в единой форме. В то же время, если вы связываетесь с внешним сервером с помощью кода SQL, подключение и информация о регистрационной записи обслуживаются разными командами.

Установка подключения

Для установки подключения к внешнему серверу с помощью программного кода используется системная хранимая процедура sp_addlinkedserver. Если соединение к удаленному серверу было установлено и имя экземпляра этого сервера доступно как имя подключения, то требуются всего два параметра: имя внешнего сервера и серверный продукт. Следующая команда создает подключение к экземпляру SQL2 на моем сервере тестирования ([XPS\Developer]):

-- Примечание: сервер разработки автора называется XPS -- Экземпляры этого сервера:

-- [XPS] SQL Server 2000 Developer Edition -- [XPS\Developer] SQL Server 2005 Developer Edition -- [XPS\SQLExpress] SQL Server 2005 Express Edition -- [XPS\Standard] SQL Server 2005 Standard Edition EXEC sp_addlinkedserver @server = 'XPS\SQLExpress',

@srvproduct = 'SQL Server1;

Если вы собираетесь запустить этот сценарий, вам потребуется изменить имя На заметку сервера и его экземпляра, чтобы они соответствовали вашей конфигурации.

Для подключения к экземпляру сервера с использованием имени, отличного от реального имени экземпляра, в инструкцию добавляются два параметра. Первый параметр, provider, должен иметь значение SQLOLEDB, а параметр @datasrc (источник данных) передает реальное имя экземпляра SQL Server. Параметр @srvproduct (серверный продукт) остается пустым. Параметр @server должен содержать имя связанного сервера, которое должно быть известно. В следующем примере показано, как выполняется подключение к экземпляру SQL2 сервера Noli, однако в запросах этот сервер будет упоминаться как Yonder:

EXEC sp_addlinkedserver @server = 1 Yonder1,

@datasrc = ,Noli\SQL2I,

@srvproduct = 1 ' ,

@provider='SQLOLEDB1;

I    Представление каталога sys . servers перечисляет все серверы, включая    под-

SVS    ключенные. Системная хранимая процедура sp_linkedservers также    воз-

I *    вращает информацию обо всех подключенных серверах.

SELECT [Имя] , Продукт, Провайдер, Источник_данных FROM sys.servers WHERE Is_Linked = 1;

Для удаления существующего подключения к серверу (не влияющего на сам внешний сервер) используется системная хранимая процедура sp_dropserver:

EXEC sp_DropServer ©server = 1 Yonder1;

Если для связанного сервера существуют какие-либо ограничения, то они также удаляются.

Распределенная защита и регистрация

В утилите Management Studio вопрос безопасности разбит на две части: отображение регистрационных данных, режим работы с не отображенными регистрациями. В Т-SQL для решения обоих вопросов используется системная хранимая процедура sp_addlinkedsrvlogin:

sp_addlinkedsrvlogin

@rmtsrvname = ' имя_удаленного_сервера' ,

@useself = 'useself', (по умолчанию True)

@locallogin = 'локальная_учетная_запись', (по умолчанию Null)

@rmtuser = 1удаленный_пользователь', (по умолчанию Null)

@rmtpassword = 1удаленный_пароль' (по умолчанию Null);

Если связанный сервер был добавлен с помощью кода Т-SQL, а не средствами Management Studio, то параметры безопасности для не отображенных регистраций уже сконфигурированы для использования текущего контекста безопасности.

Если параметр @locallogin имеет пустое значение NULL, то параметры применяются ко всем пользователям, не отображенным в списке. Параметр @useself идентичен параметру Impersonate, о котором мы говорили ранее.

Следующая хранимая процедура использует учетную запись Noli\Paul для доступа к серверу Noli\SQL2 под именем sa и с паролем secret:

sp_addlinkedsrvlogin

@rmtsrvname = 'XPS\SQLExpress1,

@useself = 'false',

@locallogin = 'NOLI\Paul',

@rmtuser = 'sa' ,

@rmtpassword = 1 secret';

В следующем примере все не отображенные в списке пользователи настраиваются для подключения с использованием собственного контекста безопасности (рекомендуемый параметр). Имя локального пользователя равно NULL, так что эта регистрация на внешнем сервере применяется ко всем пользователям, не отображенным в списке. Параметр @useself не определяется, так что используется его значение, принятое по умолчанию, — true. Это значит, что все пользователи будут использовать текущий контекст безопасности:

EXEС sp_addlinkedsrvlogin @rmtsrvname = 'NOLI\SQL2';

В третьем примере мы запретим всем не отображенным в списке пользователям выполнение распределенных запросов. В нем второй параметр, @useself, установлен в значение false, а регистрационное имя и пароль отображенных пользователей равны пустым значениям (NULL):

EXEC sp_addlinkedsrvlogin ,N0LI\SQL2'/ 'false';

I    Представление каталога sys . Linked_Logins перечисляет регистрационные

SVS    записи. Системная хранимая процедура sp_helplinkedsrvlogin также воз-

* I *    вращает информацию о подключенных регистрационных записях:

SELECT [Имя], Продукт, Провайдер, Источник_данных FROM sys.servers WHERE Is_Linked = 1;

Для сброса подключения к связанному серверу используется системная хранимая процедура sp_dropl inkedsrvlogin: sp_droplinkedsrvlogin

@rmtsrvname = 1имя_удаленного_сервера', (нет умолчаний)

@locallogin = 'локальная_учетная_запись' (нет умолчаний);

В следующем примере мы удалим регистрационную запись Noli\Paul, отображенную наNoli\SQL2:

EXEC sp_droplinkedsrvlogin

@rmtsrvname = 'XPS\SQLExpress',

@locallogin = 'NOLl\Paul';

Для удаления отображения, применяемого к не отображаемым пользователям, запустите ту же процедуру, только задайте пустую локальную учетную запись (NULL):

EXEC sp_droplinkedsrvlogin 'XPS\SQLExpress', NULL;

Параметры связанного сервера

Параметры связанного сервера, перечисленные во вкладке Server Options формы Linked Server Options, можно установить и программным путем с помощью системной хранимой процедуры sp_serveroption. Эта процедура должна вызываться для каждого из устанавливаемых параметров: sp_serveroption

@server = 'сервер',

@optname = 'имя_параметра',

@optvalue = ' значение_параметра';

Параметры в этом примере те же, что и в форме, только с дополнением параметра lazy schema validation, который отключает проверку схемы таблиц на распределенные запросы. Вы можете его использовать, когда уверены в безопасности схемы, но хотите уменьшить сетевую нагрузку.

Представление каталога sys . servers возвращает параметры связанного сервера. Системная хранимая процедура sp_helpserver также возвращает информацию о связанных серверах

Подключение к источникам данных, отличным от SQL Server

Если внешний источник данных — не SQL Server, вы все равно имеете возможность доступа к данным. Все зависит от доступности и функций драйверов ODBC или поставщиков OLE DB. SQL Server для доступа к внешним данным использует механизм OLE DB, и некоторые его компоненты входят в комплект сервера. Если по какой-либо причине OLE DB не доступен для некоторого внешнего источника данных, используйте поставщик Microsoft OLE DB Provider for ODBC Drivers. Практически любой тип источника данных имеет драйвер ODBC.

Для установки подключения к серверу либо в Management Studio, либо программным путем строке подключения требуется дополнительная информация (кроме имени подключаемого сервера, провайдера и имени продукта). Некоторые настройки распространенных источников данных приведены в табл. 15.1.

В качестве примеров подключения к источникам данных, отличным от SQL Server, мы с помощью распределенных запросов пополним учебную базу данных Cape Hateras Adventures информацией из Access и Excel. Данная учебная база данных моделирует типичный малый бизнес, который в настоящее время использует Access и Excel для хранения списка клиентов и расписания.

Таблица 15.1. Настройки подключения к другим источникам данных Подключение к... Имя провайдера Продукт Источник данных Строка провайдера

MS Access

MS Jet 4.0 OLE DB

Access 2003

Местоположение файла базы данных

null

Excel

MS Jet 4.0 OLE DB

Excel

Местоположение файла с рабочим листом

Excel 5.0

Oracle

MS OLE Provider for Oracle

Oracle

Системный идентификатор Oracle

null

 

Следующий пример кода SQL настраивает рабочую книгу Excel как связанный сервер:

Execute sp_addlinkedserver @server = 1CHAl_Schedule1,

@srvproduct = ' Excel',

@provider = 'Microsoft.Jet.OLEDB.4.0',

@datasrc = 'C:\SQLServerBible\CHAl_Schedule.xls',

@provstr = 'Excel 5.0'

Электронные книги Excel не являются многопользовательскими. По этой причине 7 На заметку    SQL Server не может выполнить распределенный запрос, в котором участвует книга Excel, пока она открыта каким-либо пользователем.

Подключение к MS Access

Неудивительно, что SQL Server без труда подключается к базам данных MS Access. SQL Server использует провайдер OLE DB Jet для доступа к механизму Jet, который задействуется программой Access для доступа к данным в файлах . mdb.

Так как программа Access сама представляет собой СУБД, не существует никаких хитростей в подготовке ее баз данных, как это было в случае с Excel. Каждая таблица базы данных Access будет отображена в виде таблицы в узле Linked Servers утилиты Management Studio.

Согласно нашему сценарию, до перехода на платформу SQL Server список клиентов хранился в базе данных Access. Следующий код, который можно взять из файла CHA2_Convert. sql, связывается с базой данных Access CHAl_Customers .mdb, чтобы СУБД SQL Server могла запросить из нее данные и заполнить собственные таблицы:

EXEC sp_addlinkedserver 'CHAl_Customers',

'Access 2003 ' ,

'Microsoft.Jet.OLEDB.4.0',

'С:\SQLServerBible\CHAl_Customers.mdb';

Если у вас появились сложности при работе с распределенными запросами, в первую очередь проверьте контекст безопасности. Access не ожидает установки какого-либо контекста безопасности, поэтому не отображенные регистрационные записи будут установлены в незащищенный контекст.

EXEC sp_addlinkedsrvlogin @rmtsrvname = 'CHAl_Schedule', @useself = 'false';

Распределенные представления

Представления — это сохраненные инструкции SQL. Хотя я не рекомендую основывать приложения клиент/сервер на представлениях, они могут оказаться полезными для текущих запросов. Так как большая часть пользователей (в том числе и разработчики) не знакома с различными методами выполнения распределенных запросов, помещение такового в представление может оказаться удачным решением проблемы.

Локальные распределенные запросы

Хотя термин локальный распределенный запрос звучит странно, все не так уж сложно. Это запрос, который собирает внешние данные в SQL Server, а затем выполняет запрос на локальном сервере. Так как обработка таких запросов выполняется на локальном сервере, в них используется синтаксис Т-SQL, и поэтому их иногда называют локальными запросами T-SQL.

Использование четырехкомпонентного имени

Если данные находятся на другом экземпляре SQL Server, то полный синтаксис четырехкомпонентного имени следующий:

Сервер. База_данных. Схема . Имя_Объекта

Четырехкомпонентное имя может использоваться в любых запросах извлечения или модификации данных. На моем компьютере существует второй экземпляр SQL Server с именем [XPS\Yukon]. Имя владельца объекта является обязательным, если обращение осуществляется к внешнему серверу.

Следующий запрос извлекает таблицу Person из экземпляра SQL2:

SELECT LastName, FirstName

FROM [XPS\Yukon].Family.dbo.person

Результат запроса следующий:

LastName FirstName

Halloway Kelly Halloway James

При выполнении инструкций INSERT, UPDATE и DELETE в качестве распределенных запросов для имени таблицы можно использовать либо четырехкомпонентную форму, либо функцию распределенного запроса. В качестве примера приведем следующий код, который можно взять из файла CHA2_Convert. sql и который заполняет учебную базу данных СНА2. В этом примере в качестве источника данных для инструкции INSERT использовано четырехкомпонентное имя таблицы. Этот запрос извлекает названия базовых лагерей из электронной таблицы Excel и вставляет их в SQL Server:

INSERT BaseCamp(Name)

SELECT DISTINCT [Base Camp]

FROM CHAl_Schedule...[Base_Camp]

WHERE [Base Camp] IS NOT NULL

Если вы уже выполняли сценарий CHA2_Convert. sql и заполнили свою ко-Совет    пию базы СНА2, еще раз запустите сценарий CHA2_Create. sql, чтобы начать

работу с пустой базы данных.

У

А вот еще один пример использования четырехкомпонентного имени для распределенного запроса. В нем обновляется база данных Family, находящаяся на другом экземпляре SQL Server:

UPDATE [Noli\SQL2].Family.dbo.Person

SET LastName = 'Wilson'

WHERE PersonID = 1

Использование функции OpenDataSource ()

Использование функции OpenDataSource () ничем не отличается от использования четырехкомпонентного имени для доступа к связанному серверу, за исключением того, что функция определяет подключение в своем теле, а не использует предопределенный связанный сервер. В то время как определение связи в программе пропускает определение самого сервера, если местонахождение связи изменяется, это коснется всех запросов, использующих функцию OpenDataSource (). К тому же функция OpenDataSource () не принимает переменные в качестве аргументов.

Функция OpenDataSource () заменяет имя сервера в четырехкомпонентном имени и может использоваться в любой инструкции DML.

Синтаксис функции OpenDataSource () выглядит довольно простым:

OpenDataSource {провайдер, строка_инициализации)

Однако первое впечатление обманчиво. Строка_инициализации представляет собой символьную строку с несколькими параметрами, разделенными точками с запятыми (точный список параметров зависит от конкретного источника данных). Потенциально в строке инициализации указывается источник данных, его местоположение, дополнительные параметры, время ожидания подключения, идентификатор пользователя, его пароль и каталог. В строке инициализации должны быть указаны все необходимые параметры подключения к источнику данных, в том числе контекст безопасности. Отдельные параметры в строке инициализации не нужно заключать в кавычки. Самой распространенной ошибкой, замеченной при реализации функции OpenDataSource (), является путаница между запятыми и точками с запятой.

Если функция OpenDataSource () подключается к другому серверу с помощью Windows, то необходима аутентификация с поддержкой Kerberos.

Вот относительно простой пример использования функции OpenDataSource () в качестве механизма доступа к таблице в другом экземпляре SQL Server:

SELECT FirstName, Gender

FROM OPENDATASOURCE(

'SQLOLEDB',

'Data Source=NOLI\SQL2;User ID=Joe;Password=j'

).Family.dbo.Person;

Результат выполнения запроса:

FirstName    Gender

Adam    M

Alexia    F

В следующем примере распределенного запроса, использующего функцию OpenDataSource (), мы ссылаемся на базу данных Cape Hatteras Adventures. Поскольку файл Access содержит всего одну базу данных и обращение к таблицам не требует указания владельца, эти части в четырехкомпонентном имени можно опустить:

SELECT ContactFirstName, ContactLastName FROM OPENDATASOURCE(

'Microsoft.Jet.OLEDB.4.0',

'Data Source =

С:\SQLServerBible\CHAl_Customers.mdb'

)...Customers;

Neal    Garrison

Melissa    Anderson

Gary    Quill

Для иллюстрации использования функции OpenUpdateSource () в запросе UPDATE мы обновим все строки в рабочей книге Excel CHAl_Schedule.xls. Именованный диапазон был определен заранее: Tours ' =Sheetl! $Е$5 : $Е$24 1. Теперь он будет использован в запросе SQL в качестве таблицы в источнике данных. Вместо того чтобы обновлять отдельно каждую ячейку рабочего листа, этот запрос выполняет инструкцию UPDATE, затрагивающую все строки, в которых названием тура является Gauley River Rafting, и обновляет столбец Base Camp значением Ashville.

Распределенный запрос SQL Server для доступа к механизму Jet, который открывает рабочий лист Excel, будет использовать поставщика OLE DB. Функции OpenDataSource () мы передаем только имя сервера в четырехкомпонентной форме; при этом, как и в случае с Access, имя базы данных и владельца опускаем:

UPDATE OpenDataSource(

'Microsoft.Jet.OLEDB.4.0',

'Data Source=C:\SQLServerBible\CHAl_Schedule. xls;

User ID=Admin;Password=;Extended properties=Excel 5.0'

)...Tour

SET [Base Camp] = 'Ashville'

WHERE Tour = 'Gauley River Rafting';

Чтобы завершить пример, следующий запрос считывает тот же рабочий лист Excel и проверяет, действительно ли имело место обновление. И снова функция OpenDataSource (), единственная в распределенном запросе, указывает на внешний сервер:

SELECT *

FROM OpenDataSource(

'Microsoft.Jet.OLEDB.4.0',

'Data Source=C:\SQLServerBible\CHAl_Schedule.xls;

User ID=Admin;Password=;Extended properties=Excel 5.0'

)...Tour

WHERE Tour = 'Gauley River Rafting';

Сквозные распределенные запросы

Сквозные запросы выполняются на внешнем источнике данных, после чего результат передается на SQL Server. Основная причина использования таких запросов заключается в сокращении объема данных, передаваемых с сервера (внешнего источника данных) и клиента (SQL Server). Вместо передачи миллиона строк на SQL Server, чтобы использовать только двадцать пять из них, может оказаться выгоднее извлечь только эти строки из внешнего источника данных.

В то же время сквозные запросы должны использовать синтаксис внешнего сервера. Если источником данных является база данных Oracle, то в сквозном запросе должен использоваться язык PL/SQL; если база данных Access — то Access SQL.

В случае сквозного запроса, модифицирующего данные, сам тип удаленных данных определяет, будет ли обновление выполняться локально или удаленно.

¦ Если обновляются данные на другом экземпляре SQL Server, то операция будет выполняться именно на нем.

¦ Если данные обновляются на сервере, отличном от SQL Server, то поставщик определяет, где именно будут обрабатываться данные. Часто передаваемые запросы просто отбирают корректные строки. Эти строки передаются на SQL Server, обновляются на нем, а затем возвращаются удаленному источнику данных для обновления.

Существуют две формы локальных распределенных запросов: одна для связанных серверов и одна для внешних источников данных, определяемых в запросе. Также существуют две формы сквозных распределенных запросов. В одном случае функция OpenQuery () использует уже подключенный сервер; во втором — функция OpenRowSet () определяет связь непосредственно в запросе.

Использование четырехкомпонентного имени

Если распределенный запрос осуществляет доступ к другому экземпляру SQL Server, четырехкомпонентное имя называют гибридным методом распределенных запросов. В зависимости от предложений FROM и WHERE, SQL Server будет пытаться передать как можно большую часть запроса удаленному серверу, чтобы увеличить производительность.

При создании сложных распределенных запросов, использующих четырехкомпонентное имя, довольно сложно предсказать заранее, какая часть запроса будет передана. Мне встречались серверы, которые, в зависимости от предложения WHERE, либо передавали весь запрос, либо каждая таблица передавала свой запрос, либо запрос передавала только одна таблица.

Из четырех представленных методов распределенных запросов лучшими являются использование четырехкомпонентного имени и функции OpenQuery () соответственно. Оба метода используют административную настройку подключения к удаленному серверу, что делает запрос более надежным, если конфи-Проверено гурация сервера изменяется.

Выбор между этими двумя методами зависит от общего объема данных, их извлекаемого количества и производительности сервера. Рекомендую вам протестировать оба метода и сравнить их планы выполнения, после чего выбрать тот, который лучше проявляет себя в вашей ситуации. Если оба метода показывают равную производительность, то используйте метод четырехкомпонентного имени, чтобы сервер имел возможность автоматически оптимизировать распределенный запрос.

Функция OpenQuery ()

Среди передаваемых запросов функция OpenQuery () задействует ресурсы уже подключенного сервера, поэтому с ней проще обращаться. Она также воспринимает изменения в конфигурации серверов без изменения кода.

Функция OpenQuery () используется в языке SQL DML в качестве таблицы. Она принимает два аргумента: имя связываемого сервера и сам передаваемый запрос. В следующем примере функция OpenQuery () используется для извлечения данных из рабочей книги Excel CHAl_Schedule:

SELECT *

FROM OPENQUERY(CHAl_Schedule,

'SELECT * FROM Tour WHERE Tour = "Gauley River Rafting"');

В следующем примере функция OpenQuery () дает указание механизму Jet, чтобы тот извлек только две строки, требующие обновления. Реальная инструкция UPDATE выполняется на сервере, а результат возвращается внешнему источнику данных. В результате передаваемый запрос выполняет в инструкции UPDATE только часть функции SELECT:

UPDATE OPENQUERY(CHAl_Schedule,

'SELECT * FROM Tour WHERE Tour = "Gauley River Rafting"')

SET [Base Camp] = 'Ashville'

WHERE Tour = 'Gauley River Rafting';

Функция OpenRowSet ()

Эта функция является двойником функции OpenDataSet (). Обе требуют, чтобы в распределенном запросе был полностью определен удаленный источник данных. Функция OpenRowSet () имеет дополнительный аргумент, определяющий передаваемый запрос:

SELECT ContactFirstName, ContactLastName

FROM OPENROWSET ('Microsoft.Jet.OLEDB.4.0', 'C:\SQLServerBible\CHAl_Customers.mdb'; 'Admin'; ' ' ,

'SELECT * FROM Customers WHERE CustomerlD = 1');

Чтобы выполнить обновление с помощью функции OpenRowSet (), вставьте ее на место модифицируемой таблицы. В следующем примере мы изменим фамилию заказчика в базе данных Access. Предложение WHERE инструкции UPDATE обрабатывается передаваемой частою функции OpenRowSet ():

UPDATE OPENROWSET ('Microsoft.Jet.OLEDB.4.0',

'C:\SQLServerBible\CHAl_Customers.mdb'; 'Admin'

'SELECT * FROM Customers WHERE CustomerlD = 1')

SET ContactLastName = 'Wilson';

Операции массового заполнения поддерживаются функцией OpenRowSet (), и это существенно повышает их производительность.