Обновление адаптера таблицы TableAdapter для использования JOIN (VB)

Скотт Митчелл

Загрузить PDF-файл

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

Введение

В реляционных базах данных данные, с которыми нам нужно работать, часто распределяются по нескольким таблицам. Например, при отображении сведений о продукте мы, скорее всего, захотите перечислить соответствующие категории и названия поставщиков каждого продукта. Таблица Products содержит CategoryID значения и SupplierID , но фактические имена категорий и поставщиков находятся в Categories таблицах и Suppliers соответственно.

Чтобы получить сведения из другой связанной таблицы, можно использовать коррелированные вложенные запросы или JOINs. Связанный вложенный запрос — это вложенный SELECT запрос, который ссылается на столбцы во внешнем запросе. Например, в учебнике Создание уровня доступа к данным мы использовали два коррелированных вложенных запроса в ProductsTableAdapter запросе main для возврата категорий и имен поставщиков для каждого продукта. — JOIN это конструкция SQL, которая объединяет связанные строки из двух разных таблиц. Мы использовали в учебнике Запрос данных с элементом управления SqlDataSource для отображения сведений JOIN о категории вместе с каждым продуктом.

Причина, по которой мы воздерживались от использования JOIN объектов с TableAdapters, заключается в ограничениях мастера TableAdapter для автоматического создания соответствующих INSERTинструкций , UPDATEи DELETE . В частности, если запрос main TableAdapter содержит какие-либо JOIN объекты , TableAdapter не может автоматически создать нерегламентированные инструкции SQL или хранимые процедуры для своих InsertCommandсвойств , UpdateCommandи DeleteCommand .

В этом руководстве мы кратко сравним и сопоставим коррелированные вложенные запросы и JOIN запросы, прежде чем изучить, как создать TableAdapter, который включает JOIN в main запрос.

Сравнение и контрастирование коррелированных вложенных запросов иJOIN запросов

Напомним, что объект , ProductsTableAdapter созданный в первом учебнике в Northwind DataSet, использует коррелированные вложенные запросы, чтобы вернуть каждому продукту соответствующую категорию и имя поставщика. Ниже ProductsTableAdapter показан запрос main.

SELECT ProductID, ProductName, SupplierID, CategoryID, 
       QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, 
       ReorderLevel, Discontinued,
       (SELECT CategoryName FROM Categories WHERE Categories.CategoryID = 
            Products.CategoryID) as CategoryName, 
       (SELECT CompanyName FROM Suppliers WHERE Suppliers.SupplierID = 
            Products.SupplierID) as SupplierName
FROM Products

Два коррелированных вложенных запроса - (SELECT CategoryName FROM Categories WHERE Categories.CategoryID = Products.CategoryID) и (SELECT CompanyName FROM Suppliers WHERE Suppliers.SupplierID = Products.SupplierID) - являются SELECT запросами, которые возвращают одно значение для каждого продукта в качестве дополнительного столбца в списке столбцов внешней SELECT инструкции.

Кроме того, JOIN можно использовать для возврата имени поставщика и категории каждого продукта. Следующий запрос возвращает те же выходные данные, что и приведенный выше, но вместо вложенных запросов использует JOIN s:

SELECT ProductID, ProductName, Products.SupplierID, Products.CategoryID, 
       QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, 
       ReorderLevel, Discontinued,
       Categories.CategoryName, 
       Suppliers.CompanyName as SupplierName
FROM Products
    LEFT JOIN Categories ON
        Categories.CategoryID = Products.CategoryID
    LEFT JOIN Suppliers ON
        Suppliers.SupplierID = Products.SupplierID

Объединяет JOIN записи из одной таблицы с записями из другой таблицы на основе некоторых критериев. В приведенном выше запросе, например, указывает SQL Server LEFT JOIN Categories ON Categories.CategoryID = Products.CategoryID объединить каждую запись продукта с записью категории, значение которой CategoryID соответствует значению продуктаCategoryID. Объединенный результат позволяет работать с соответствующими полями категории для каждого продукта (например, CategoryName).

Примечание

JOIN обычно используются при запросе данных из реляционных баз данных. Если вы не знакомы с синтаксисом JOIN или вам нужно немного освежить его использование, я рекомендую руководство по присоединению к SQL в W3 Schools. Также стоит ознакомиться с JOIN разделами Основы и Основы вложенных запросов электронной документации по SQL.

Так как JOIN s и коррелированные вложенные запросы можно использовать для извлечения связанных данных из других таблиц, многие разработчики остаются в голове и задаются вопросом, какой подход использовать. Все гуру SQL, с которыми я говорил, говорили примерно то же самое, что это не имеет значения с точки зрения производительности, так как SQL Server будет производить примерно одинаковые планы выполнения. Таким образом, они советуют использовать метод, который вам и вашей команде удобнее всего. Следует отметить, что после того, как эти эксперты сразу же выражают свое предпочтение JOIN по сравнению с коррелированные вложенные запросы.

При создании уровня доступа к данным с помощью типизированных наборов данных эти средства лучше работают при использовании вложенных запросов. В частности, мастер TableAdapter не будет автоматически создавать соответствующие INSERTинструкции , и DELETE , UPDATEесли запрос main содержит какие-либо JOIN , но будет автоматически создавать эти инструкции при использовании коррелированных вложенных запросов.

Чтобы изучить этот недостаток, создайте временный типизированный набор данных в папке ~/App_Code/DAL . В мастере настройки TableAdapter выберите использование нерегламентированных инструкций SQL и введите следующий SELECT запрос (см. рис. 1):

SELECT ProductID, ProductName, Products.SupplierID, Products.CategoryID, 
       QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, 
       ReorderLevel, Discontinued,
       Categories.CategoryName, 
       Suppliers.CompanyName as SupplierName
FROM Products
    LEFT JOIN Categories ON
        Categories.CategoryID = Products.CategoryID
    LEFT JOIN Suppliers ON
        Suppliers.SupplierID = Products.SupplierID

Рис. 1. Введите основной запрос, содержащий JOIN s (щелкните для просмотра полноразмерного изображения)

По умолчанию TableAdapter автоматически создает INSERTинструкции , UPDATEи DELETE на основе запроса main. Если нажать кнопку Дополнительно, вы увидите, что эта функция включена. Несмотря на этот параметр, TableAdapter не сможет создать INSERTоператоры , и DELETE , UPDATEтак как запрос main содержит JOIN.

Рис. 2. Ввод основного запроса, содержащего JOIN элементы

Чтобы завершить работу мастера, нажмите кнопку Готово. На этом этапе Designer DataSet будет включать один объект TableAdapter с таблицей DataTable со столбцами для каждого поля, возвращаемого в списке SELECT столбцов запроса. Сюда входят и SupplierName, как показано на CategoryName рисунке 3.

Рис. 3. DataTable содержит столбец для каждого поля, возвращаемого в списке столбцов

Хотя таблица DataTable содержит соответствующие столбцы, tableAdapter не имеет значений для свойств InsertCommand, UpdateCommandи DeleteCommand . Чтобы подтвердить это, щелкните TableAdapter в Designer и перейдите к окно свойств. Там вы увидите InsertCommand, что свойства , UpdateCommandи DeleteCommand имеют значение (None) .

Рис. 4. Свойства InsertCommand, UpdateCommandи DeleteCommand имеют значение (Нет) (щелкните для просмотра полноразмерного изображения)

Чтобы обойти этот недостаток, можно вручную предоставить инструкции и параметры SQL для InsertCommandсвойств , UpdateCommandи DeleteCommand с помощью окно свойств. Кроме того, можно начать с настройки запроса main TableAdapter, чтобы они не включали какие-либоJOIN. Это позволит INSERTавтоматически создавать операторы , UPDATEи DELETE . После завершения работы мастера можно вручную обновить tableAdapter SelectCommand из окно свойств, чтобы он включает JOIN синтаксис.

Хотя этот подход работает, он очень хрупкий при использовании нерегламентированных SQL-запросов, так как каждый раз, когда запрос main TableAdapter повторно настраивается с помощью мастера, автоматически созданные INSERTинструкции , UPDATEи DELETE создаются заново. Это означает, что все настройки, которые мы позже внесли, будут потеряны, если щелкнуть правой кнопкой мыши TableAdapter, выбрать Настроить в контекстном меню и снова завершить работу мастера.

К счастью, хрупкость автоматически создаваемых INSERTинструкций TableAdapter , UPDATEи DELETE ограничена нерегламентированными инструкциями SQL. Если в TableAdapter используются хранимые процедуры, можно настроить SelectCommandхранимые процедуры , InsertCommand, UpdateCommandили DeleteCommand и повторно запустить мастер настройки TableAdapter, не опасаясь, что хранимые процедуры будут изменены.

В течение следующих нескольких шагов мы создадим объект TableAdapter, который изначально использует main запрос, который пропускает все JOIN s, чтобы соответствующие хранимые процедуры вставки, обновления и удаления были созданы автоматически. Затем мы обновим SelectCommand , чтобы использовать JOIN , который возвращает дополнительные столбцы из связанных таблиц. Наконец, мы создадим соответствующий класс уровня бизнес-логики и продемонстрируем использование TableAdapter на веб-странице ASP.NET.

Шаг 1. Создание объекта TableAdapter с помощью упрощенного основного запроса

В этом руководстве мы добавим TableAdapter и строго типизированную таблицу Employees DataTable для таблицы в наборе NorthwindWithSprocs данных. Таблица Employees содержит ReportsTo поле, указывающее EmployeeID руководителя сотрудника. Например, сотрудник Энн Додсворт имеет ReportTo значение 5, которое является стивеном EmployeeID Бьюкененом. Следовательно, Энн подчитывает Стивену, ее менеджеру. Наряду с отчетом о значении ReportsTo каждого сотрудника мы также можем получить имя его руководителя. Это можно сделать с помощью JOIN. Однако использование при первоначальном JOIN создании TableAdapter не позволяет мастеру автоматически создавать соответствующие возможности вставки, обновления и удаления. Поэтому мы начнем с создания объекта TableAdapter, main запрос которого не содержит никаких JOIN значений . Затем на шаге 2 мы обновим main хранимую процедуру запроса, чтобы получить имя руководителя с помощью JOIN.

Начните с открытия NorthwindWithSprocs Набора данных в папке ~/App_Code/DAL . Щелкните правой кнопкой мыши Designer, выберите пункт Добавить в контекстном меню и выберите пункт меню TableAdapter. Откроется мастер настройки TableAdapter. Как показано на рисунке 5, мастер должен создать новые хранимые процедуры и нажать кнопку Далее. Дополнительные сведения о создании новых хранимых процедур в мастере TableAdapter см. в руководстве Создание новых хранимых процедур для typed DataSets TableAdapters .

Рис. 5. Выберите параметр Создать хранимые процедуры (щелкните, чтобы просмотреть полноразмерное изображение)

Используйте следующую SELECT инструкцию для запроса main TableAdapter:

SELECT EmployeeID, LastName, FirstName, Title, HireDate, ReportsTo, Country
FROM Employees

Так как этот запрос не содержит элементов JOIN , мастер TableAdapter автоматически создаст хранимые процедуры с соответствующими INSERTинструкциями , UPDATEи DELETE , а также хранимую процедуру для выполнения запроса main.

Следующий шаг позволяет присвоить имя хранимым процедурам TableAdapter. Используйте имена Employees_Select, Employees_Insert, Employees_Updateи Employees_Delete, как показано на рис. 6.

Рис. 6. Имя хранимых процедур TableAdapter (щелкните, чтобы просмотреть полноразмерное изображение)

На последнем шаге предлагается присвоить имена методам TableAdapter. Используйте Fill и GetEmployees в качестве имен методов. Также не забудьте оставить флажок Создать методы для отправки обновлений непосредственно в базу данных (GenerateDBDirectMethods).

Рис. 7. Назовите методы Fill TableAdapter и GetEmployees (щелкните, чтобы просмотреть полноразмерное изображение)

После завершения работы мастера изучите хранимые процедуры в базе данных. Вы увидите четыре новых: Employees_Select, Employees_Insert, Employees_Updateи Employees_Delete. Затем проверьте только что созданные EmployeesDataTable и EmployeesTableAdapter . DataTable содержит столбец для каждого поля, возвращаемого запросом main. Щелкните TableAdapter и перейдите к окно свойств. Там вы увидите InsertCommand, что свойства , UpdateCommandи DeleteCommand правильно настроены для вызова соответствующих хранимых процедур.

Рис. 8. TableAdapter включает возможности вставки, обновления и удаления (щелкните для просмотра полноразмерного изображения)

После автоматического создания хранимых процедур вставки, обновления и удаления и InsertCommandправильной настройки свойств , UpdateCommandи DeleteCommand мы готовы настроить SelectCommand хранимую процедуру для возврата дополнительных сведений о руководителе каждого сотрудника. В частности, необходимо обновить хранимую Employees_SelectJOIN процедуру для использования и вернуть значения и значения диспетчера FirstNameLastName . После обновления хранимой процедуры необходимо обновить таблицу DataTable, чтобы она включила эти дополнительные столбцы. Мы рассмотрим эти две задачи в шагах 2 и 3.

Шаг 2. Настройка хранимой процедуры для включенияJOIN

Для начала перейдите в Обозреватель Server, развернете папку Хранимые процедуры базы данных Northwind и откройте хранимую Employees_Select процедуру. Если эта хранимая процедура не отображается, щелкните правой кнопкой мыши папку Хранимые процедуры и выберите Обновить. Обновите хранимую процедуру, чтобы она возвращала LEFT JOIN имя и фамилию руководителя:

SELECT Employees.EmployeeID, Employees.LastName, 
       Employees.FirstName, Employees.Title, 
       Employees.HireDate, Employees.ReportsTo, 
       Employees.Country,
       Manager.FirstName as ManagerFirstName, 
       Manager.LastName as ManagerLastName
FROM Employees
    LEFT JOIN Employees AS Manager ON
        Employees.ReportsTo = Manager.EmployeeID

После обновления инструкции SELECT сохраните изменения, перейдя в меню Файл и выбрав Сохранить Employees_Select. Кроме того, можно щелкнуть значок Сохранить на панели инструментов или нажать клавиши CTRL+S. После сохранения изменений щелкните правой кнопкой мыши хранимую Employees_Select процедуру в Обозреватель сервера и выберите команду Выполнить. При этом будет запущена хранимая процедура и ее результаты отображаются в окне Вывод (см. рис. 9).

Рис. 9. Результаты хранимых процедур отображаются в окне вывода (щелкните для просмотра полноразмерного изображения)

Шаг 3. Обновление столбцов DataTable

На этом этапе хранимая Employees_Select процедура возвращает ManagerFirstName значения и ManagerLastName , но EmployeesDataTable эти столбцы отсутствуют. Эти отсутствующие столбцы можно добавить в таблицу Данных одним из двух способов:

• Вручную щелкните правой кнопкой мыши DataTable в Designer DataSet и в меню Добавить выберите Столбец. Затем можно присвоить столбцу имя и задать его свойства соответствующим образом.
• Автоматически — мастер настройки TableAdapter обновит столбцы DataTable в соответствии с полями, возвращаемыми хранимой SelectCommand процедурой. При использовании нерегламентированных инструкций SQL мастер также удалит InsertCommandсвойства , и DeleteCommand , UpdateCommandтак как SelectCommand теперь содержит JOIN. Но при использовании хранимых процедур эти свойства команд остаются неизменными.

Мы изучили добавление столбцов DataTable вручную в предыдущих руководствах, в том числе Master/Detail Using a Bulleted List of Master Records with a Details DataList и Uploading Files, и мы рассмотрим этот процесс более подробно в следующем руководстве. Однако в этом руководстве мы будем использовать автоматический подход с помощью мастера настройки TableAdapter.

Для начала щелкните правой кнопкой EmployeesTableAdapter мыши и выберите Пункт Настроить в контекстном меню. Откроется мастер настройки TableAdapter, в котором перечислены хранимые процедуры, используемые для выбора, вставки, обновления и удаления, а также возвращаемые значения и параметры (если таковые есть). На рисунке 10 показан этот мастер. Здесь видно, что хранимая Employees_Select процедура теперь возвращает ManagerFirstName поля и ManagerLastName .

Рис. 10. Мастер показывает обновленный список столбцов для хранимой Employees_Select процедуры (щелкните для просмотра полноразмерного изображения)

Завершите работу мастера, нажав кнопку Готово. При возвращении к Designer EmployeesDataTable DataSet включает два дополнительных столбца: ManagerFirstName и ManagerLastName.

Рис. 11. Содержит EmployeesDataTable два новых столбца (щелкните для просмотра полноразмерного изображения)

Чтобы продемонстрировать, что обновленная Employees_Select хранимая процедура действует и что возможности вставки, обновления и удаления TableAdapter по-прежнему работают, создадим веб-страницу, которая позволяет пользователям просматривать и удалять сотрудников. Однако перед созданием такой страницы необходимо сначала создать новый класс на уровне бизнес-логики для работы с сотрудниками из NorthwindWithSprocs DataSet. На шаге 4 мы создадим EmployeesBLLWithSprocs класс . На шаге 5 мы будем использовать этот класс со страницы ASP.NET.

Шаг 4. Реализация уровня бизнес-логики

Создайте файл класса в папке ~/App_Code/BLL с именем EmployeesBLLWithSprocs.vb. Этот класс имитирует семантику существующего EmployeesBLL класса, только этот новый предоставляет меньше методов и использует NorthwindWithSprocs DataSet (вместо Northwind DataSet). Добавьте в класс EmployeesBLLWithSprocs приведенный далее код.

Imports NorthwindWithSprocsTableAdapters
<System.ComponentModel.DataObject()> _
Public Class EmployeesBLLWithSprocs
    Private _employeesAdapter As EmployeesTableAdapter = Nothing
    Protected ReadOnly Property Adapter() As EmployeesTableAdapter
        Get
            If _employeesAdapter Is Nothing Then
                _employeesAdapter = New EmployeesTableAdapter()
            End If
            Return _employeesAdapter
        End Get
    End Property
    <System.ComponentModel.DataObjectMethodAttribute _
        (System.ComponentModel.DataObjectMethodType.Select, True)> _
    Public Function GetEmployees() As NorthwindWithSprocs.EmployeesDataTable
        Return Adapter.GetEmployees()
    End Function
    <System.ComponentModel.DataObjectMethodAttribute _
        (System.ComponentModel.DataObjectMethodType.Delete, True)> _
    Public Function DeleteEmployee(ByVal employeeID As Integer) As Boolean
        Dim rowsAffected = Adapter.Delete(employeeID)
        'Return true if precisely one row was deleted, otherwise false
        Return rowsAffected = 1
    End Function
End Class

Свойство EmployeesBLLWithSprocs класса возвращает Adapter экземпляр NorthwindWithSprocs объекта DataSet .EmployeesTableAdapter Используется методами класса s GetEmployees и DeleteEmployee . Метод GetEmployees вызывает соответствующий EmployeesTableAdapterGetEmployees метод , который вызывает хранимую Employees_Select процедуру и заполняет ее результаты в .EmployeeDataTable Метод DeleteEmployee аналогичным образом вызывает EmployeesTableAdapter метод s Delete , который вызывает хранимую Employees_Delete процедуру.

Шаг 5. Работа с данными на уровне представления

EmployeesBLLWithSprocs После завершения класса мы готовы к работе с данными сотрудников на странице ASP.NET. Откройте страницу JOINs.aspx в папке AdvancedDAL и перетащите GridView с панели элементов на Designer, установив для его ID свойства значение Employees. Затем из смарт-тега GridView привяжите сетку к новому элементу управления ObjectDataSource с именем EmployeesDataSource.

Настройте ObjectDataSource для использования EmployeesBLLWithSprocs класса и на вкладках SELECT и DELETE убедитесь, что GetEmployees методы и DeleteEmployee выбраны из раскрывающихся списков. Нажмите кнопку Готово, чтобы завершить настройку ObjectDataSource.

Рис. 12. Настройка ObjectDataSource для использования EmployeesBLLWithSprocs класса (щелкните для просмотра полноразмерного изображения)

Рис. 13. Использование методов и DeleteEmployee в объекте ObjectDataSource GetEmployees (щелкните для просмотра полноразмерного изображения)

Visual Studio добавит BoundField в GridView для каждого столбца EmployeesDataTable . Удалите все эти поля BoundField, кроме Title, LastName, FirstNameManagerFirstNameи ManagerLastName переименуйте HeaderText свойства для последних четырех Полей BoundField на Last Name, First Name, Manager s First Name и Manager s Last Name соответственно.

Чтобы разрешить пользователям удалять сотрудников с этой страницы, необходимо выполнить два действия. Сначала попросите GridView предоставить возможности удаления, установив флажок Включить удаление из смарт-тега. Во-вторых, измените свойство ObjectDataSource OldValuesParameterFormatString из значения, заданного мастером ObjectDataSource (original_{0}), на его значение по умолчанию ({0}). После внесения этих изменений декларативная разметка GridView и ObjectDataSource должна выглядеть примерно так:

<asp:GridView ID="Employees" runat="server" AutoGenerateColumns="False" 
    DataKeyNames="EmployeeID" DataSourceID="EmployeesDataSource">
    <Columns>
        <asp:CommandField ShowDeleteButton="True" />
        <asp:BoundField DataField="Title" 
            HeaderText="Title" 
            SortExpression="Title" />
        <asp:BoundField DataField="LastName" 
            HeaderText="Last Name" 
            SortExpression="LastName" />
        <asp:BoundField DataField="FirstName" 
            HeaderText="First Name" 
            SortExpression="FirstName" />
        <asp:BoundField DataField="ManagerFirstName" 
            HeaderText="Manager's First Name" 
            SortExpression="ManagerFirstName" />
        <asp:BoundField DataField="ManagerLastName" 
            HeaderText="Manager's Last Name" 
            SortExpression="ManagerLastName" />
    </Columns>
</asp:GridView>
<asp:ObjectDataSource ID="EmployeesDataSource" runat="server" 
    DeleteMethod="DeleteEmployee" OldValuesParameterFormatString="{0}" 
    SelectMethod="GetEmployees" TypeName="EmployeesBLLWithSprocs">
    <DeleteParameters>
        <asp:Parameter Name="employeeID" Type="Int32" />
    </DeleteParameters>
</asp:ObjectDataSource>

Протестируйте страницу, посетив ее в браузере. Как показано на рисунке 14, на странице будут перечислены имена каждого сотрудника и его руководителя (при условии, что у них есть имя).

Рис. 14. В JOIN хранимой Employees_Select процедуре возвращается имя руководителя (щелкните для просмотра полноразмерного изображения)

Нажатие кнопки Удалить запускает рабочий процесс удаления, который завершается выполнением хранимой Employees_Delete процедуры. Однако попытка выполнения инструкции в хранимой процедуре завершается DELETE сбоем из-за нарушения ограничения внешнего ключа (см. рис. 15). В частности, у каждого сотрудника есть одна или несколько записей в Orders таблице, что приводит к сбою удаления.

Рис. 15. Удаление сотрудника с соответствующими заказами приводит к нарушению ограничения внешнего ключа (щелкните для просмотра полноразмерного изображения)

Чтобы разрешить удаление сотрудника, вы можете:

• Обновите ограничение внешнего ключа для каскадного удаления.
• Вручную удалите записи из Orders таблицы для сотрудников, которые вы хотите удалить, или
• Обновите хранимую Employees_Delete процедуру, чтобы сначала удалить связанные записи из Orders таблицы перед удалением Employees записи. Мы обсудили этот метод в учебнике Использование существующих хранимых процедур для адаптеров таблиц typed DataSet .

Я оставляю это как упражнение для читателя.

Сводка

При работе с реляционными базами данных запросы обычно извлекают данные из нескольких связанных таблиц. Коррелированные вложенные запросы и JOIN предоставляют два разных метода доступа к данным из связанных таблиц в запросе. В предыдущих руководствах мы чаще всего использовали коррелированные вложенные запросы, так как TableAdapter не может автоматически создавать INSERTинструкции , UPDATEи DELETE для запросов, в которых JOIN участвуют . Хотя эти значения можно указать вручную, при использовании нерегламентированных инструкций SQL любые настройки будут перезаписаны после завершения работы мастера настройки TableAdapter.

К счастью, адаптеры Таблиц, созданные с помощью хранимых процедур, не страдают от той же хрупкости, что и те, которые были созданы с помощью нерегламентированных инструкций SQL. Таким образом, при использовании хранимых процедур можно создать TableAdapter, в main запросе которого используется JOIN . В этом руководстве мы узнали, как создать такой объект TableAdapter. Мы начали использовать JOINзапрос -less SELECT для запроса main TableAdapter, чтобы соответствующие хранимые процедуры вставки, обновления и удаления создавались автоматически. После завершения начальной настройки TableAdapter мы дополнили хранимую SelectCommandJOIN процедуру для использования и повторно запустили мастер настройки TableAdapter для обновления EmployeesDataTable столбцов s.

Повторное выполнение мастера настройки TableAdapter автоматически обновило EmployeesDataTable столбцы, отражая поля данных, возвращаемые хранимой Employees_Select процедурой. Кроме того, мы могли бы добавить эти столбцы вручную в таблицу DataTable. В следующем руководстве мы рассмотрим добавление столбцов в таблицу DataTable вручную.

Счастливого программирования!

Об авторе

Скотт Митчелл( Scott Mitchell), автор семи книг ASP/ASP.NET и основатель 4GuysFromRolla.com, работает с веб-технологиями Майкрософт с 1998 года. Скотт работает независимым консультантом, тренером и писателем. Его последняя книга Sams Teach Yourself ASP.NET 2.0 в 24 часа. Его можно связать по адресу mitchell@4GuysFromRolla.com. или через его блог, который можно найти по адресу http://ScottOnWriting.NET.

Отдельная благодарность

Эта серия учебников была проверена многими полезными рецензентами. Ведущие рецензенты этого руководства : Хилтон Гейсеноу, Дэвид Суру и Тереса Мерфи. Хотите ознакомиться с моими предстоящими статьями MSDN? Если да, опустите мне строку в mitchell@4GuysFromRolla.com.

НазадВперед