Uppdatera TableAdapter för att använda JOINs (VB)

av Scott Mitchell

Ladda ned PDF

När du arbetar med en databas är det vanligt att begära data som är spridda över flera tabeller. För att hämta data från två olika tabeller kan vi använda en korrelerad underfråga eller en JOIN-åtgärd. I den här självstudien jämför vi korrelerade underfrågor och JOIN-syntaxen innan vi tittar på hur du skapar en TableAdapter som innehåller en JOIN i huvudfrågan.

Inledning

Med relationsdatabaser är de data vi är intresserade av att arbeta med ofta spridda över flera tabeller. När vi till exempel visar produktinformation vill vi förmodligen lista varje produkts motsvarande kategori och leverantörsnamn. Tabellen Products har CategoryID och SupplierID värden, men den faktiska kategorin och leverantörsnamnen finns i tabellerna Categories respektive Suppliers tabellerna.

Om du vill hämta information från en annan relaterad tabell kan vi antingen använda korrelerade underfrågor eller JOINs. En korrelerad underfråga är en kapslad SELECT fråga som refererar till kolumner i den yttre frågan. I självstudien Skapa ett dataåtkomstlager använde vi till exempel två korrelerade underfrågor i ProductsTableAdapter huvudfrågan för att returnera kategorin och leverantörsnamnen för varje produkt. A JOIN är en SQL-konstruktion som sammanfogar relaterade rader från två olika tabeller. Vi använde en JOIN i självstudien Fråga data med SqlDataSource Control för att visa kategoriinformation tillsammans med varje produkt.

Anledningen till att vi har avstått från att använda JOIN s med TableAdapters är på grund av begränsningar i TableAdapter-guiden för att generera motsvarande INSERT, UPDATEoch DELETE -instruktioner automatiskt. Mer specifikt, om huvudfrågan i TableAdapter innehåller några JOIN-element, kan TableAdapter inte automatiskt skapa ad hoc SQL-uttryck eller lagrade procedurer för sina InsertCommand, UpdateCommand och DeleteCommand-egenskaper.

I den här självstudien jämför och kontrasterar vi korrelerade underfrågor och JOIN s innan vi utforskar hur du skapar en TableAdapter som innehåller JOIN s i huvudfrågan.

Jämföra och kontrastera korrelerade underfrågor ochJOIN s

Kom ihåg att den ProductsTableAdapter som skapades i den första självstudien Northwind i DataSet använder korrelerade underfrågor för att ta tillbaka varje produkts motsvarande kategori och leverantörsnamn. Huvudfrågan ProductsTableAdapter visas nedan.

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

De två korrelerade underfrågorna – (SELECT CategoryName FROM Categories WHERE Categories.CategoryID = Products.CategoryID) och (SELECT CompanyName FROM Suppliers WHERE Suppliers.SupplierID = Products.SupplierID) – är SELECT frågor som returnerar ett enda värde per produkt som en ytterligare kolumn i den yttre SELECT instruktionens kolumnlista.

Alternativt kan en JOIN användas för att returnera varje produkts leverantör och kategorinamn. Följande fråga returnerar samma utdata som ovan, men använder JOIN s i stället för underfrågor:

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

A JOIN sammanfogar posterna från en tabell med poster från en annan tabell baserat på vissa villkor. I frågan ovan instruerar till exempel LEFT JOIN Categories ON Categories.CategoryID = Products.CategoryID SQL Server att slå samman varje produktpost med kategoriposten vars CategoryID värde matchar produktens CategoryID värde. Det sammanslagna resultatet gör att vi kan arbeta med motsvarande kategorifält för varje produkt (till exempel CategoryName).

Eftersom JOIN s och korrelerade underfrågor både kan användas för att hämta relaterade data från andra tabeller, får många utvecklare klia sig i huvudet och undrar vilken metod de ska använda. Alla SQL-gurus som jag har pratat med har sagt ungefär samma sak, att det egentligen inte spelar någon roll prestandamässigt eftersom SQL Server kommer att producera ungefär identiska körningsplaner. Deras råd är då att använda den teknik som du och ditt team är mest bekväma med. Det förtjänar att notera att efter att ha förmedlat detta råd uttrycker dessa experter omedelbart sin preferens av JOIN s framför korrelerade underfrågor.

När du skapar ett dataåtkomstlager med hjälp av typerade datauppsättningar fungerar verktygen bättre när du använder underfrågor. I synnerhet genererar guiden TableAdapter s inte motsvarande INSERT, UPDATEoch DELETE -instruktioner automatiskt om huvudfrågan innehåller några JOIN s, men genererar dessa instruktioner automatiskt när korrelerade underfrågor används.

Om du vill utforska den här bristen skapar du en tillfällig Typed DataSet i ~/App_Code/DAL mappen . Under guiden Konfiguration av TableAdapter väljer du att använda ad hoc SQL-instruktioner och anger följande SELECT fråga (se bild 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

Bild 1: Ange en huvudfråga som innehåller JOIN (Klicka om du vill visa en bild i full storlek)

Som standardinställning skapar TableAdapter automatiskt INSERT, UPDATE, och DELETE-instruktioner baserat på huvudfrågan. Om du klickar på knappen Avancerat kan du se att den här funktionen är aktiverad. Trots den här inställningen kommer TableAdapter inte att kunna skapa INSERT, UPDATE och DELETE uttryck, eftersom huvudfrågan innehåller en JOIN.

Bild 2: Ange en huvudfråga som innehåller JOIN s

Klicka på Slutför för att slutföra guiden. I det här läget innehåller DataSet s Designer en enda TableAdapter med en DataTable med kolumner för vart och ett av fälten som returneras i SELECT frågekolumnlistan. Detta inkluderar CategoryName och SupplierName, som bild 3 visar.

Bild 3: DataTabellen innehåller en kolumn för varje fält som returneras i kolumnlistan

Även om DataTable har lämpliga kolumner saknar TableAdapter värden för dess InsertCommandegenskaper , UpdateCommandoch DeleteCommand . Bekräfta detta genom att klicka på TableAdapter i designern och sedan gå till fönstret Egenskaper. Där ser du att InsertCommandegenskaperna , UpdateCommandoch DeleteCommand är inställda på (Ingen) .

Bild 4: Egenskaperna InsertCommand, UpdateCommandoch DeleteCommand är inställda på (Ingen) (Klicka om du vill visa en bild i full storlek)

För att undvika den här bristen kan vi manuellt ange SQL-instruktioner och parametrar för InsertCommandegenskaperna , UpdateCommandoch DeleteCommand via fönstret Egenskaper. Vi kan också börja med att konfigurera TableAdapter-huvudfrågan så att den inte innehåller några JOIN s. På så sätt kan INSERT- UPDATEoch-uttrycken DELETE genereras automatiskt åt oss. När du har slutfört guiden kan vi sedan uppdatera TableAdapter s SelectCommand manuellt från fönstret Egenskaper så att den innehåller syntaxen JOIN .

Även om den här metoden fungerar är den mycket skör när du använder ad hoc-SQL-frågor, eftersom varje gång TableAdapter-huvudfrågan konfigureras om via guiden återskapas de automatiskt genererade INSERT, UPDATEoch DELETE -instruktionerna. Det innebär att alla anpassningar som vi gjorde senare skulle gå förlorade om vi högerklickade på TableAdapter, valde Konfigurera från snabbmenyn och slutförde guiden igen.

Skörheten i TableAdapter:s automatiskt genererade INSERT, UPDATEoch DELETE -instruktioner är lyckligtvis begränsad till ad hoc SQL-instruktioner. Om TableAdapter använder lagrade procedurer kan du anpassa SelectCommand, InsertCommand, UpdateCommandeller DeleteCommand lagrade procedurer och köra konfigurationsguiden TableAdapter igen utan att behöva frukta att de lagrade procedurerna kommer att ändras.

Under de kommande stegen skapar vi en TableAdapter som till en början använder en huvudfråga som utelämnar alla JOIN s så att motsvarande infognings-, uppdaterings- och borttagningsprocedurer genereras automatiskt. Sedan uppdaterar SelectCommand vi så att den använder en JOIN som returnerar ytterligare kolumner från relaterade tabeller. Slutligen skapar vi en motsvarande Business Logic Layer-klass och demonstrerar med TableAdapter på en ASP.NET webbsida.

Steg 1: Skapa TableAdapter med hjälp av en förenklad huvudfråga

I den här handledningen lägger vi till en TableAdapter och en starkt typad DataTable för Employees-tabellen i NorthwindWithSprocs-DataSet. Tabellen Employees innehåller ett ReportsTo fält som angav medarbetarens EmployeeID chef. Till exempel har medarbetaren Anne Dodsworth värdet ReportTo 5, vilket är EmployeeID Steven Buchanans värde. Därför rapporterar Anne till Steven, hennes chef. Tillsammans med att rapportera varje medarbetares ReportsTo värde kanske vi också vill hämta namnet på deras chef. Detta kan åstadkommas med hjälp av en JOIN. Men om du använder en JOIN när du först skapar TableAdapter hindras guiden från att automatiskt generera motsvarande infognings-, uppdaterings- och borttagningsfunktioner. Därför börjar vi med att skapa en TableAdapter vars huvudfråga inte innehåller några JOIN s. I steg 2 kommer vi sedan att uppdatera den lagrade proceduren för huvudfrågan för att hämta chefens namn via en JOIN.

Börja med att NorthwindWithSprocs öppna DataSet i ~/App_Code/DAL mappen . Högerklicka på designern, välj alternativet Lägg till på snabbmenyn och välj menyalternativet TableAdapter. Då startas konfigurationsguiden för TableAdapter. Som bild 5 visar, låt guiden skapa nya lagrade procedurer och klicka på Nästa. Information om hur du skapar nya lagrade procedurer med hjälp av TableAdapter-guiden finns i självstudien Skapa nya lagrade procedurer för Typed DataSets TableAdapters.

Bild 5: Välj alternativet Skapa nya lagrade procedurer (Klicka om du vill visa en bild i full storlek)

Använd följande SELECT instruktion för TableAdapter-huvudfrågan:

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

Eftersom den här frågan inte innehåller några JOIN s skapar guiden TableAdapter automatiskt lagrade procedurer med motsvarande INSERT, UPDATEoch DELETE -instruktioner samt en lagrad procedur för att köra huvudfrågan.

I följande steg kan vi namnge TableAdapter-lagrade procedurer. Använd namnen Employees_Select, Employees_Insert, Employees_Updateoch Employees_Delete, enligt bild 6.

Bild 6: Namnge lagrade procedurer för TableAdapter (Klicka för att visa bilden i full storlek)

Det sista steget uppmanar oss att namnge TableAdapter-metoderna. Använd Fill och GetEmployees som metodnamn. Se också till att lämna kryssrutan Skapa metoder för att skicka uppdateringar direkt till databasen (GenerateDBDirectMethods) markerad.

Bild 7: Namnge TableAdapter-metoderna Fill och GetEmployees (Klicka om du vill visa en bild i full storlek)

När du har slutfört guiden kan du titta närmare på de lagrade procedurerna i databasen. Du bör se fyra nya: Employees_Select, Employees_Insert, Employees_Updateoch Employees_Delete. Granska sedan EmployeesDataTable och EmployeesTableAdapter som just har skapats. DataTable innehåller en kolumn för varje fält som returneras av huvudfrågan. Klicka på TableAdapter och gå sedan till fönstret Egenskaper. Där ser du att InsertCommandegenskaperna , UpdateCommandoch DeleteCommand är korrekt konfigurerade för att anropa motsvarande lagrade procedurer.

Bild 8: TableAdapter innehåller funktionerna Infoga, Uppdatera och Ta bort (Klicka om du vill visa en bild i full storlek)

Med infognings-, uppdaterings- och borttagningsprocedurerna som skapas automatiskt och InsertCommand-, UpdateCommand-, och DeleteCommand-egenskaperna är korrekt konfigurerade, är vi redo att anpassa den SelectCommand-lagrade proceduren för att returnera ytterligare information om varje anställds manager. Mer specifikt behöver vi uppdatera den Employees_Select lagrade proceduren för att använda en JOIN och returnera chefernas FirstName och LastName värdena. När den lagrade proceduren har uppdaterats måste vi uppdatera DataTable så att den innehåller dessa ytterligare kolumner. Vi tar itu med dessa två uppgifter i steg 2 och 3.

Steg 2: Anpassa den lagrade proceduren så att den innehåller enJOIN

Börja med att gå till Server Explorer, gå ned i mappen Lagrade procedurer i Northwind-databasen och öppna den Employees_Select lagrade proceduren. Om du inte ser den här lagrade proceduren högerklickar du på mappen Lagrade procedurer och väljer Uppdatera. Uppdatera den lagrade proceduren så att den använder en LEFT JOIN för att returnera chefens för- och efternamn:

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

När du har uppdaterat instruktionen SELECT sparar du ändringarna genom att gå till menyn Arkiv och välja Spara Employees_Select. Du kan också klicka på ikonen Spara i verktygsfältet eller trycka på Ctrl+S. När du har sparat ändringarna högerklickar du på den Employees_Select lagrade proceduren i Serverutforskaren och väljer Kör. Då körs den lagrade proceduren och dess resultat visas i fönstret Utdata (se bild 9).

Bild 9: Resultatet av lagrade procedurer visas i utdatafönstret (klicka om du vill visa en bild i full storlek)

Steg 3: Uppdatera kolumnerna i DataTable s

I det här läget returnerar den lagrade proceduren Employees_Select värdena ManagerFirstName och ManagerLastName, men saknar EmployeesDataTable dessa kolumner. Dessa saknade kolumner kan läggas till i DataTable på något av två sätt:

• Manuellt – högerklicka på DataTable i DataSet Designer och välj Kolumn på menyn Lägg till. Du kan sedan namnge kolumnen och ange dess egenskaper i enlighet med detta.
• Automatiskt – guiden TableAdapter Configuration uppdaterar DataTable-kolumnerna så att de återspeglar de fält som returneras av den SelectCommand lagrade proceduren. När du använder ad hoc SQL-instruktioner tar guiden också bort InsertCommandegenskaperna , UpdateCommandoch DeleteCommand eftersom nu SelectCommand innehåller en JOIN. Men när du använder lagrade procedurer förblir dessa kommandoegenskaper intakta.

Vi har utforskat att lägga till DataTable-kolumner manuellt i tidigare handledningar, inklusive Master/Detail Using a Bulleted List of Master Records with a Details DataList och Uploading Files, och vi kommer att undersöka processen mer ingående i vår nästa handledning. I den här självstudien ska vi dock använda den automatiska metoden via guiden Konfiguration av TableAdapter.

Börja med att högerklicka på EmployeesTableAdapter och välja Konfigurera på snabbmenyn. På så sätt visas konfigurationsguiden TableAdapter, som visar de lagrade procedurer som används för att välja, infoga, uppdatera och ta bort, tillsammans med deras returvärden och parametrar (om några). Bild 10 visar den här guiden. Här kan vi se att den Employees_Select lagrade proceduren nu returnerar fälten ManagerFirstName och ManagerLastName .

Bild 10: Guiden visar den uppdaterade kolumnlistan för den Employees_Select lagrade proceduren (Klicka om du vill visa en bild i full storlek)

Slutför guiden genom att klicka på Avsluta. När du återvänder till DataSet Designer innehåller de EmployeesDataTable ytterligare två kolumnerna: ManagerFirstName och ManagerLastName.

Bild 11: Innehåller EmployeesDataTable två nya kolumner (Klicka om du vill visa en bild i full storlek)

För att illustrera att den uppdaterade Employees_Select lagrade proceduren är i kraft och att funktionerna infoga, uppdatera och ta bort i TableAdapter fortfarande fungerar kan vi skapa en webbsida där användarna kan visa och ta bort anställda. Innan vi skapar en sådan sida måste vi dock först skapa en ny klass i affärslogiklagret för att arbeta med anställda från NorthwindWithSprocs DataSet. I steg 4 skapar vi en EmployeesBLLWithSprocs klass. I steg 5 använder vi den här klassen från en ASP.NET sida.

Steg 4: Implementera affärslogiklagret

Skapa en ny klassfil i ~/App_Code/BLL mappen med namnet EmployeesBLLWithSprocs.vb. Den här klassen efterliknar semantiken i den befintliga EmployeesBLL klassen, endast den nya innehåller färre metoder och använder NorthwindWithSprocs DataSet (i stället för Northwind DataSet). Lägg till följande kod i EmployeesBLLWithSprocs klassen.

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

Egenskapen EmployeesBLLWithSprocs class s Adapter returnerar en instans av NorthwindWithSprocs DataSet s EmployeesTableAdapter. Detta används av klassen GetEmployees och DeleteEmployee metoderna. Metoden GetEmployees anropar EmployeesTableAdapter motsvarande GetEmployees metod, som anropar den Employees_Select lagrade proceduren och fyller i dess resultat i en EmployeeDataTable. Metoden DeleteEmployee anropar på samma sätt EmployeesTableAdapter metoden Delete, som anropar den lagrade proceduren Employees_Delete.

Steg 5: Arbeta med data i presentationslagret

När klassen är EmployeesBLLWithSprocs klar är vi redo att arbeta med medarbetardata via en ASP.NET sida. Öppna sidan JOINs.aspx i AdvancedDAL mappen och dra en GridView från verktygslådan till designern och ange dess ID egenskap till Employees. Från GridViews smarta tagg binder du sedan rutnätet till en ny ObjectDataSource-kontroll med namnet EmployeesDataSource.

Konfigurera ObjectDataSource för att använda EmployeesBLLWithSprocs-klassen och se till att GetEmployees- och DeleteEmployee-metoderna är valda från listrutorna på flikarna SELECT och DELETE. Klicka på Slutför för att slutföra ObjectDataSource-konfigurationen.

Bild 12: Konfigurera ObjectDataSource att använda EmployeesBLLWithSprocs klassen (Klicka om du vill visa en bild i full storlek)

Bild 13: Be ObjectDataSource använda GetEmployees metoderna och DeleteEmployee (klicka om du vill visa en bild i full storlek)

Visual Studio lägger till ett BoundField i GridView för var och en av s-kolumnerna EmployeesDataTable . Ta bort alla dessa BoundFields förutom Title, LastName, FirstName, ManagerFirstName och ManagerLastName och byt namn på HeaderText-egenskaperna för de fyra sista BoundFields till Efternamn, Förnamn, Chefens förnamn respektive Chefens efternamn.

För att tillåta användare att ta bort anställda från den här sidan måste vi göra två saker. Instruera först GridView att tillhandahålla borttagningsfunktioner genom att kontrollera alternativet Aktivera borttagning från dess smarta tagg. För det andra ändrar du egenskapen ObjectDataSource från OldValuesParameterFormatString värdet som anges av guiden ObjectDataSource (original_{0}) till dess standardvärde ({0}). När du har gjort dessa ändringar bör deklarativa markeringarna för GridView och ObjectDataSource se ut ungefär så här:

<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>

Testa sidan genom att besöka den via en webbläsare. Som bild 14 visar visar sidan varje anställd och hans eller hennes chefs namn (förutsatt att de har ett).

Bild 14: I JOIN den Employees_Select lagrade proceduren returneras chefens namn (klicka om du vill visa en bild i full storlek)

När du klickar på knappen Ta bort startas arbetsflödet för borttagning, vilket kulminerar i körningen av den Employees_Delete lagrade proceduren. Instruktionsförsöket i den lagrade DELETE proceduren misslyckas dock på grund av en begränsningsöverträdelse för främmande nyckel (se bild 15). Mer specifikt har varje anställd en eller flera poster i Orders tabellen, vilket gör att borttagningen misslyckas.

Bild 15: Om du tar bort en anställd som har motsvarande beställningar resulterar det i en överträdelse av begränsning för utländsk nyckel (klicka för att visa bilden i full storlek)

Om du vill tillåta att en anställd tas bort kan du:

• Uppdatera restriktionen för främmande nyckel till att säkerställa kaskadbegränsad borttagning.
• Ta bort posterna från Orders tabellen manuellt för de anställda som du vill ta bort, eller
• Uppdatera den Employees_Delete lagrade proceduren för att först ta bort relaterade poster från Orders tabellen innan du tar bort posten Employees . Vi diskuterade den här tekniken i handledningen Använda befintliga lagrade procedurer för Typed DataSet's TableAdapters.

Jag lämnar detta som en övning för läsaren.

Sammanfattning

När du arbetar med relationsdatabaser är det vanligt att frågor hämtar sina data från flera relaterade tabeller. Korrelerade underfrågor och JOIN s tillhandahåller två olika tekniker för att komma åt data från relaterade tabeller i en fråga. I tidigare självstudier använde vi vanligtvis korrelerade underfrågor eftersom TableAdapter inte automatiskt kan generera INSERT, UPDATEoch DELETE -instruktioner för frågor som rör JOIN s. Dessa värden kan anges manuellt, men när du använder ad hoc SQL-instruktioner skrivs alla anpassningar över när guiden TableAdapter-konfiguration har slutförts.

Lyckligtvis lider TableAdapters som skapats med lagrade procedurer inte av samma skörhet som de som skapats med hjälp av ad hoc SQL-instruktioner. Därför är det möjligt att skapa en TableAdapter vars huvudfråga använder en JOIN när du använder lagrade procedurer. I den här självstudien såg vi hur man skapar en sådan TableAdapter. Vi började med att använda en fråga utan JOIN för TableAdapters huvudfråga så att motsvarande infognings-, uppdaterings- och borttagningsprocedurer kunde skapas automatiskt. När TableAdapter-konfigurationen har slutförts utökade vi den SelectCommand lagrade proceduren för att använda en JOIN och körde tabelladapterkonfigurationsguiden igen för att uppdatera EmployeesDataTable s-kolumnerna.

Genom att köra om konfigurationsguiden TableAdapter kommer kolumnerna EmployeesDataTable automatiskt att uppdateras så att de återspeglar de datafält som returneras av den lagrade proceduren Employees_Select. Vi kan också ha lagt till dessa kolumner manuellt i DataTable. Vi kommer att utforska hur du lägger till kolumner i DataTable manuellt i nästa självstudie.

Lycka till med programmerandet!

Om författaren

Scott Mitchell, författare till sju ASP/ASP.NET-böcker och grundare av 4GuysFromRolla.com, har arbetat med Microsofts webbtekniker sedan 1998. Scott arbetar som oberoende konsult, tränare och författare. Hans senaste bok är Sams Teach Yourself ASP.NET 2.0 på 24 timmar. Han kan nås på mitchell@4GuysFromRolla.com.

Särskilt tack till

Den här självstudieserien granskades av många användbara granskare. Huvudgranskare för den här självstudien var Hilton Geisenow, David Suru och Teresa Murphy. Vill du granska mina kommande MSDN-artiklar? Om så är fallet, hör av dig på mitchell@4GuysFromRolla.com.