Dinesh Kulkarni, Luca Bolognese, Matt Warren, Anders Hejlsberg, Kit George
March 2007
Applies to: Visual Studio Code Name "Orcas" .Net Framework 3.5
Summary: LINQ to SQL provides a runtime infrastructure for managing relational data as objects without losing the ability to query. Your application is free to manipulate the objects while LINQ to SQL stays in the background tracking your changes automatically. (119 printed pages)
ContentsIntroductionA Quick TourCreating Entity ClassesThe DataContextDefining RelationshipsQuerying Across RelationshipsModifying and Saving EntitiesQueries In-DepthQuery ExecutionObject IdentityRelationshipsJoinsProjectionsCompiled QueriesSQL TranslationThe Entity LifecycleTracking ChangesSubmitting ChangesSimultaneous ChangesTransactionsStored Procedures Entity Classes In-DepthUsing AttributesGraph ConsistencyChange NotificationsInheritanceAdvanced TopicsCreating DatabasesInteroperating with ADO.NETChange Conflict ResolutionStored Procedures InvocationThe Entity Class Generator ToolGenerator Tool DBML ReferenceMulti-tier EntitiesExternal MappingNET Framework Function Support and NotesDebugging Support
IntroductionMost programs written today manipulate data in one way or another and often this data is stored in a relational database. Yet there is a huge divide between modern programming languages and databases in how they represent and manipulate information. This impedance mismatch is visible in multiple ways. Most notable is that programming languages access information in databases through APIs that require queries to be specified as text strings. These queries are significant portions of the program logic. Yet they are opaque to the language, unable to benefit from compile-time verification and design-time features like IntelliSense.
Of course, the differences go far deeper than that. How information is represented—the data model—is quite different between the two. Modern programming languages define information in the form of objects. Relational databases use rows. Objects have unique identity as each instance is physically different from another. Rows are identified by primary key values. Objects have references that identify and link instances together. Rows are left intentionally distinct requiring related rows to be tied together loosely using foreign keys. Objects stand alone, existing as long as they are still referenced by another object. Rows exist as elements of tables, vanishing as soon as they are removed.
It is no wonder that applications expected to bridge this gap are difficult to build and maintain. It would certainly simplify the equation to get rid of one side or the other. Yet relational databases provide critical infrastructure for long-term storage and query processing, and modern programming languages are indispensable for agile development and rich computation.
Until now, it has been the job of the application developer to resolve this mismatch in each application separately. The best solutions so far have been elaborate database abstraction layers that ferry the information between the applications domain-specific object models and the tabular representation of the database, reshaping and reformatting the data each way. Yet by obscuring the true data source, these solutions end up throwing away the most compelling feature of relational databases; the ability for the data to be queried.
LINQ to SQL, a component of Visual Studio Code Name "Orcas", provides a run-time infrastructure for managing relational data as objects without losing the ability to query. It does this by translating language-integrated queries into SQL for execution by the database, and then translating the tabular results back into objects you define. Your application is then free to manipulate the objects while LINQ to SQL stays in the background tracking your changes automatically.
LINQ to SQL is designed to be non-intrusive to your application.It is possible to migrate current ADO.NET solutions to LINQ to SQL in a piecemeal fashion (sharing the same connections and transactions) since LINQ to SQL is simply another component in the ADO.NET family. LINQ to SQL also has extensive support for stored procedures, allowing reuse of the existing enterprise assets.
LINQ to SQL applications are easy to get started.Objects linked to relational data can be defined just like normal objects, only decorated with attributes to identify how properties correspond to columns. Of course, it is not even necessary to do this by hand. A design-time tool is provided to automate translating pre-existing relational database schemas into object definitions for you.
Together, the LINQ to SQL run-time infrastructure and design-time tools significantly reduce the workload for the database application developer. The following chapters provide an overview of how LINQ to SQL can be used to perform common database-related tasks. It is assumed that the reader is familiar with Language-Integrated Query and the standard query operators.
LINQ to SQL is language-agnostic. Any language built to provide Language-Integrated Query can use it to enable access to information stored in relational databases. The samples in this document are shown in both C# and Visual Basic; LINQ to SQL can be used with the LINQ-enabled version of the Visual Basic compiler as well.
A Quick TourThe first step in building a LINQ to SQL application is declaring the object classes you will use to represent your application data. Let's walk through an example.
Creating Entity ClassesWe will start with a simple class Customer and associate it with the customers table in the Northwind sample database. To do this, we need only apply a custom attribute to the top of the class declaration. LINQ to SQL defines the Table attribute for this purpose.
C#
[Table(Name="Customers")]public class Customer{ public string CustomerID; public string City;} Visual Basic
_Public Class Customer Public CustomerID As String Public City As StringEnd Class The Table attribute has a Name property that you can use to specify the exact name of the database table. If no Name property is supplied, LINQ to SQL will assume the database table has the same name as the class. Only instances of classes declared as tables will be stored in the database. Instances of these types of classes are known as entities.The classes themselves are known as entity classes.
In addition to associating classes to tables you will need to denote each field or property you intend to associate with a database column. For this, LINQ to SQL defines the Column attribute.
C#
[Table(Name="Customers")]public class Customer{ [Column(IsPrimaryKey=true)] public string CustomerID; [Column] public string City;} Visual Basic
_Public Class Customer _ Public CustomerID As String _ Public City As StringEnd Class The Column attribute has a variety of properties you can use to customize the exact mapping between your fields and the database columns. One property of note is the Id property. It tells LINQ to SQL that the database column is part of the primary key in the table.
As with the Table attribute, you only need to supply information in the Column attribute if it differs from what can be deduced from your field or property declaration. In this example, you need to tell LINQ to SQL that the CustomerID field is part of the primary key in the table, yet you don't have to specify the exact name or type.
Only fields and properties declared as columns will be persisted to or retrieved from the database. Others will be considered as transient parts of your application logic.
The DataContextThe DataContext is the main conduit by which you retrieve objects from the database and resubmit changes. You use it in the same way that you would use an ADO.NET Connection. In fact, the DataContext is initialized with a connection or connection string you supply. The purpose of the DataContext is to translate your requests for objects into SQL queries made against the database and then assemble objects out of the results. The DataContext enables language-integrated query by implementing the same operator pattern as the standard query operators such as Where and Select.For example, you can use the DataContext to retrieve customer objects whose city is London as follows:
C#
// DataContext takes a connection string DataContext db = new DataContext("c:\\northwind\\northwnd.mdf");// Get a typed table to run queriesTable Customers = db.GetTable();// Query for customers from Londonvar q = from c in Customers where c.City == "London" select c;foreach (var cust in q) Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City); Visual Basic
' DataContext takes a connection string Dim db As DataContext = New DataContext("c:\northwind\northwnd.mdf")' Get a typed table to run queriesDim Customers As Customers(Of Customer) = db.GetTable(Of Customer)()' Query for customers from LondonDim londonCustomers = From customer in Customers _ Where customer.City = "London" _ Select customerFor Each cust in londonCustomers Console.WriteLine("id = " & cust.CustomerID & ", City = " & cust.City)Next Each database table is represented as a Table collection, accessible via the GetTable() method using its entity class to identify it. It is recommended that you declare a strongly typed DataContext instead of relying on the basic DataContext class and the GetTable() method. A strongly typed DataContext declares all Table collections as members of the context.
C#
public partial class Northwind : DataContext{ public Table Customers; public Table Orders; public Northwind(string connection): base(connection) {}} Visual Basic
Partial Public Class Northwind Inherits DataContext Public Customers As Table(Of Customers) Public Orders As Table(Of Orders) Public Sub New(ByVal connection As String) MyBase.New(connection) End SubEnd Class The query for customers from London can then be expressed more simply as:
C#
Northwind db = new Northwind("c:\\northwind\\northwnd.mdf");var q = from c in db.Customers where c.City == "London" select c;foreach (var cust in q) Console.WriteLine("id = {0}, City = {1}",cust.CustomerID, cust.City); Visual Basic
Dim db = New Northwind("c:\northwind\northwnd.mdf")Dim londonCustomers = From cust In db.Customers _ Where cust.City = "London" _ Select custFor Each cust in londonCustomers Console.WriteLine("id = {0}, City = {1}", cust.CustomerID, cust.City) Next We will continue to use the strongly typed Northwind class for the remainder of the overview document.
Defining RelationshipsRelationships in relational databases are typically modeled as foreign key values referring to primary keys in other tables. To navigate between them, you must explicitly bring the two tables together using a relational join operation. Objects, on the other hand, refer to each other using property references or collections of references navigated using "dot" notation. Obviously, dotting is simpler than joining, since you need not recall the explicit join condition each time you navigate.
For data relationships such as these that will always be the same, it becomes quite convenient to encode them as property references in your entity class. LINQ to SQL defines an Association attribute you can apply to a member used to represent a relationship. An association relationship is one like a foreign-key to primary-key relationship that is made by matching column values between tables.
C#
[Table(Name="Customers")]public class Customer{ [Column(Id=true)] public string CustomerID; ... private EntitySet _Orders; [Association(Storage="_Orders", OtherKey="CustomerID")] public EntitySet Orders { get { return this._Orders; } set { this._Orders.Assign(value); } }} Visual Basic
_Public Class Customer _ Public CustomerID As String ... Private _Orders As EntitySet(Of Order) _ Public Property Orders() As EntitySet(Of Order) Get Return Me._Orders End Get Set(ByVal value As EntitySet(Of Order)) End Set End PropertyEnd Class The Customer class now has a property that declares the relationship between customers and their orders. The Orders property is of type EntitySet because the relationship is one-to-many. We use the OtherKey property in the Association attribute to describe how this association is done. It specifies the names of the properties in the related class to be compared with this one. There was also a ThisKey property we did not specify. Normally, we would use it to list the members on this side of the relationship. However, by omitting it we allow LINQ to SQL to infer them from the members that make up the primary key.
Notice how this is reversed in the definition for the Order class.
C#
[Table(Name="Orders")]public class Order{ [Column(Id=true)] public int OrderID; [Column] public string CustomerID; private EntityRef _Customer; [Association(Storage="_Customer", ThisKey="CustomerID")] public Customer Customer { get { return this._Customer.Entity; } set { this._Customer.Entity = value; } }} Visual Basic
_Public Class Order _ Public OrderID As String _ Public CustomerID As String Private _Customer As EntityRef(Of Customer) _ Public Property Customer() As Customer Get Return Me._Customer.Entity End Get Set(ByVal value As Customer) Me._Customers.Entity = value End Set End PropertyEnd Class The Order class uses the EntityRef type to describe the relationship back to the customer. The use of the EntityRef class is required to support deferred loading (discussed later). The Association attribute for the Customer property specifies the ThisKey property since the non-inferable members are now on this side of the relationship.
Also take a look at the Storage property. It tells LINQ to SQL which private member is used to hold the value of the property. This allows LINQ to SQL to bypass your public property accessors when it stores and retrieves their value. This is essential if you want LINQ to SQL to avoid any custom business logic written into your accessors. If the storage property is not specified, the public accessors will be used instead. You may use the Storage property with Column attributes as well.
Once you introduce relationships in your entity classes, the amount of code you need to write grows as you introduce support for notifications and graph consistency. Fortunately, there is a tool (described later) that can be used to generate all the necessary definitions as partial classes, allowing you to use a mix of generated code and custom business logic.
For the rest of this document, we assume the tool has been used to generate a complete Northwind data context and all entity classes.
Querying Across RelationshipsNow that you have relationships, you can use them when you write queries simply by referring to the relationship properties defined in your class.
C#
var q = from c in db.Customers from o in c.Orders where c.City == "London" select new { c, o }; Visual Basic
Dim londonCustOrders = From cust In db.Customers, ord In cust.Orders _ Where cust.City = "London" _ Select Customer = cust, Order = ord The above query uses the Orders property to form the cross product between customers and orders, producing a new sequence of Customer and Order pairs.
It's also possible to do the reverse.
C#
var q = from o in db.Orders where o.Customer.City == "London" select new { c = o.Customer, o }; Visual Basic
Dim londonCustOrders = From ord In db.Orders _ Where ord.Customer.City = "London" _ Select Customer = ord.Customer, Order = ord In this example, the orders are queried and the Customer relationship is used to access information on the associated Customer object.
Modifying and Saving EntitiesFew applications are built with only query in mind. Data must be created and modified, too. LINQ to SQL is designed to offer maximum flexibility in manipulating and persisting changes made to your objects. As soon as entity objects are available—either by retrieving them through a query or constructing them anew—you may manipulate them as normal objects in your application, changing their values or adding and removing them from collections as you see fit. LINQ to SQL tracks all your changes and is ready to transmit them back to the database as soon as you are done.
The example below uses the Customer and Order classes generated by a tool from the metadata of the entire Northwind sample database. The class definitions have not been shown for brevity.
C#
Northwind db = new Northwind("c:\\northwind\\northwnd.mdf");// Query for a specific customerstring id = "ALFKI";var cust = db.Customers.Single(c => c.CustomerID == id);// Change the name of the contactcust.ContactName = "New Contact";// Create and add a new Order to Orders collectionOrder ord = new Order { OrderDate = DateTime.Now };cust.Orders.Add(ord);// Ask the DataContext to save all the changesdb.SubmitChanges(); Visual Basic
Dim db As New Northwind("c:\northwind\northwnd.mdf")' Query for a specific customerDim id As String = "ALFKI"Dim targetCustomer = (From cust In db.Customers _ Where cust.CustomerID = id).First' Change the name of the contacttargetCustomer.ContactName = "New Contact"' Create and add a new Order to Orders collectionDim id = New Order With { .OrderDate = DateTime.Now }targetCustomer.Orders.Add(ord)' Ask the DataContext to save all the changesdb.SubmitChanges() When SubmitChanges() is called, LINQ to SQL automatically generates and executes SQL commands in order to transmit the changes back to the database. It is also possible to override this behavior with custom logic. The custom logic may call a database stored procedure.
Queries In-DepthLINQ to SQL provides an implementation of the standard query operators for objects associated with tables in a relational database. This chapter describes the LINQ to SQL-specific aspects of queries.
Query ExecutionWhether you write a query as a high-level query expression or build one out of the individual operators, the query that you write is not an imperative statement executed immediately. It is a description. For example, in the declaration below the local variable q refers to the description of the query not the result of executing it.
C#
var q = from c in db.Customers where c.City == "London" select c;foreach (Customer c in q) Console.WriteLine(c.CompanyName); Visual Basic
Dim londonCustomers = From cust In db.Customers _ where cust.City = "London"For Each cust In londonCustomers Console.WriteLine(cust.CompanyName) Next The actual type of q in this instance is IQueryable. It's not until the application attempts to enumerate the contents of the query that it actually executes. In this example the foreach statement causes the execution to occur.
An IQueryable object is similar to an ADO.NET command object. Having one in hand does not imply that a query was executed. A command object holds onto a string that describes a query. Likewise, an IQueryable object holds onto a description of a query encoded as a data structure known as an Expression. A command object has an ExecuteReader() method that causes execution, returning results as a DataReader. An IQueryable object has a GetEnumerator() method that causes the execution, returning results as an IEnumerator.
Therefore, it follows that if a query is enumerated twice it will be executed twice.
C#
var q = from c in db.Customers where c.City == "London" select c;// Execute first timeforeach (Customer c in q) Console.WriteLine(c.CompanyName);// Execute second timeforeach (Customer c in q) Console.WriteLine(c.CompanyName); Visual Basic
Dim londonCustomers = From cust In db.Customers _ where cust.City = "London"' Execute first timeFor Each cust In londonCustomers Console.WriteLine(cust.CompanyName) Next' Execute second timeFor Each cust In londonCustomers Console.WriteLine(cust.CustomerID) Next This behavior is known as deferred execution. Just like with an ADO.NET command object it is possible to hold onto a query and re-execute it.
Of course, application writers often need to be very explicit about where and when a query is executed. It would be unexpected if an application were to execute a query multiple times simply because it needed to examine the results more than once. For example, you may want to bind the results of a query to something like a DataGrid. The control may enumerate the results each time it paints on the screen.
To avoid executing multiple times convert the results into any number of standard collection classes. It is easy to convert the results into a list or array using the standard query operators ToList() or ToArray().C#
var q = from c in db.Customers where c.City == "London" select c;// Execute once using ToList() or ToArray()var list = q.ToList();foreach (Customer c in list) Console.WriteLine(c.CompanyName);foreach (Customer c in list) Console.WriteLine(c.CompanyName); Visual Basic
Dim londonCustomers = From cust In db.Customers _ where cust.City = "London"' Execute once using ToList() or ToArray()Dim londonCustList = londonCustomers.ToList()' Neither of these iterations re-executes the queryFor Each cust In londonCustList Console.WriteLine(cust.CompanyName)NextFor Each cust In londonCustList Console.WriteLine(cust.CompanyName)Next One benefit of deferred execution is that queries may be piecewise constructed with execution only occurring when the construction is complete. You can start out composing a portion of a query, assigning it to a local variable and then sometime later continue applying more operators to it.
C#
var q = from c in db.Customers where c.City == "London" select c;if (orderByLocation) { q = from c in q orderby c.Country, c.City select c;}else if (orderByName) { q = from c in q orderby c.ContactName select c;}foreach (Customer c in q) Console.WriteLine(c.CompanyName); Visual Basic
Dim londonCustomers = From cust In db.Customers _ where cust.City = "London"if orderByLocation Then londonCustomers = From cust in londonCustomers _ Order By cust.Country, cust.CityElse If orderByName Then londonCustomers = From cust in londonCustomers _ Order By cust.ContactNameEnd IfFor Each cust In londonCustList Console.WriteLine(cust.CompanyName)Next In this example, q starts out as a query for all customers in London. Later on it changes into an ordered query depending on application state. By deferring execution the query can be constructed to suit the exact needs of the application without requiring risky string manipulation.
Object IdentityObjects in the runtime have unique identity. If two variables refer to the same object, they are actually referring to the same object instance. Because of this, changes made via a path through one variable are immediately visible through the other. Rows in a relational database table do not have unique identity. However, they do have a primary key and that primary key may be unique, meaning no two rows may share the same key. Yet this only constrains the contents of the database table. Therefore, as long as we only interact with the data through remote commands, it amounts to about the same thing.
However, this is rarely the case. Most often data is brought out of the database and into a different tier where an application manipulates it. Clearly, this is the model that LINQ to SQL is designed to support. When the data is brought out of the database as rows, there is no expectation that two rows representing the same data actually correspond to the same row instances. If you query for a specific customer twice, you get two rows of data, each containing the same information.
Yet with objects, you expect something quite different. You expect that if you ask the DataContext for the same information again, it will in fact give you back the same object instance. You expect this because objects have special meaning for your application and you expect them to behave like normal objects. You designed them as hierarchies or graphs and you certainly expect to retrieve them as such, without hordes of replicated instances merely because you asked for the same thing twice.
Because of this, the DataContext manages object identity. Whenever a new row is retrieved from the database, it is logged in an identity table by its primary key and a new object is created. Whenever that same row is retrieved again, the original object instance is handed back to the application. In this way, the DataContext translates the databases concept of identity (keys) into the languages concept (instances). The application only ever sees the object in the state that it was first retrieved. The new data, if different, is thrown away.
You might be puzzled by this, since why would any application throw data away? As it turns out this is how LINQ to SQL manages integrity of the local objects and is able to support optimistic updates. Since the only changes that occur after the object is initially created are those made by the application, the intent of the application is clear. If changes by an outside party have occurred in the interim they will be identified at the time SubmitChanges() is called. More of this is explained in the Simultaneous Changes section.
Note that, in the case that the database contains a table without a primary key, LINQ to SQL allows queries to be submitted over the table, but it doesn't allow updates. This is because the framework cannot identify which row to update given the lack of a unique key.
Of course, if the object requested by the query is easily identifiable by its primary key as one already retrieved no query is executed at all. The identity table acts as a cache storing all previously retrieved objects.
RelationshipsAs we saw in the quick tour, references to other objects or collections of other objects in your class definitions directly correspond to foreign-key relationships in the database. You can use these relationships when you query by simply using dot notation to access the relationship properties, navigating from one object to another. These access operations translate to more complicated joins or correlated sub-queries in the equivalent SQL, allowing you to walk through your object graph during a query. For example, the following query navigates from orders to customers as a way to restrict the results to only those orders for customers located in London.
C#
var q = from o in db.Orders where o.Customer.City == "London" select o; Visual Basic
Dim londonOrders = From ord In db.Orders _ where ord.Customer.City = "London" If relationship properties did not exist you would have to write them out manually as joins just as you would do in a SQL query.
C#
var q = from c in db.Customers join o in db.Orders on c.CustomerID equals o.CustomerID where c.City == "London" select o; Visual Basic
Dim londonOrders = From cust In db.Customers _ Join ord In db.Orders _ On cust.CustomerID Equals ord.CustomerID _ Where ord.Customer.City = "London" _ Select ord The relationship property allows you to define this particular relationship once enabling the use of the more convenient dot syntax. However, this is not the reason why relationship properties exist. They exist because we tend to define our domain-specific object models as hierarchies or graphs. The objects we choose to program against have references to other objects. It's only a happy coincidence that since object-to-object relationships correspond to foreign key style relationships in databases that property access leads to a convenient way to write joins.
Therefore, the existence of relationship properties is more important on the results side of a query than as part of the query itself. Once you have your hands on a particular customer, its class definition tells you that customers have orders. So when you look into the Orders property of a particular customer you expect to see the collection populated with all the customer's orders, since that is in fact the contract you declared by defining the classes this way. You expect to see the orders there even if you did not particularly ask for orders up front. You expect your object model to maintain an illusion that it is an in-memory extension of the database, with related objects immediately available.
LINQ to SQL implements a technique called deferred loading in order to help maintain this illusion. When you query for an object you actually only retrieve the objects you asked for. The related objects are not automatically fetched at the same time. However, the fact that the related objects are not already loaded is not observable since as soon as you attempt to access them a request goes out to retrieve them.
C#
var q = from o in db.Orders where o.ShipVia == 3 select o;foreach (Order o in q) { if (o.Freight > 200) SendCustomerNotification(o.Customer); ProcessOrder(o);} Visual Basic
Dim shippedOrders = From ord In db.Orders _ where ord.ShipVia = 3For Each ord In shippedOrders If ord.Freight > 200 Then SendCustomerNotification(ord.Customer) ProcessOrder(ord) End IfNext For example, you may want to query for a particular set of orders and then only occasionally send an email notification to particular customers. You would not necessary need to retrieve all customer data up front with every order. Deferred loading allows you to defer the cost of retrieving extra information until you absolutely have to.
Of course, the opposite might also be true. You might have an application that needs to look at customer and order data at the same time. You know you need both sets of data. You know your application is going to drill down through each customer's orders as soon as you get them. It would be unfortunate to fire off individual queries for orders for every customer. What you really want to happen is to have the order data retrieved together with the customers.
C#
var q = from c in db.Customers where c.City == "London" select c;foreach (Customer c in q) { foreach (Order o in c.Orders) { ProcessCustomerOrder(o); }} Visual Basic
Dim londonCustomers = From cust In db.Customer _ Where cust.City = "London"For Each cust In londonCustomers For Each ord In cust.Orders ProcessCustomerOrder(ord) End IfNext Certainly, you can always find a way to join customers and orders together in a query by forming the cross product and retrieving all the relative bits of data as one big projection. But then the results would not be entities. Entities are objects with identity that you can modify while the results would be projections that cannot be changed and persisted. Worse, you would be retrieving a huge amount of redundant data as each customer repeats for each order in the flattened join output.
What you really need is a way to retrieve a set of related objects at the same time—a delineated portion of a graph so you would never be retrieving any more or any less than was necessary for your intended use.
LINQ to SQL allows you to request immediate loading of a region of your object model for just this reason. It does this by allowing the specification of a DataShape for a DataContext. The DataShape class is used to instruct the framework about which objects to retrieve when a particular type is retrieved. This is accomplished by using the LoadWith method as in the following:
C#
DataShape ds = new DataShape();ds.LoadWith(c => c.Orders);db.Shape = ds;var q = from c in db.Customers where c.City == "London" select c; Visual Basic
Dim ds As DataShape = New DataShape()ds.LoadWith(Of Customer)(Function(c As Customer) c.Orders)db.Shape = dsDim londonCustomers = From cust In db.Customers _ Where cust.City = "London" _ Select cust In the previous query, all the Orders for all the Customers who live in London are retrieved when the query is executed, so that successive access to the Orders property on a Customer object doesn't trigger a database query.
The DataShape class can also be used to specify sub-queries that are applied to a relationship navigation. For example, if you want to retrieve just the Orders that have been shipped today, you can use the AssociateWith method on the DataShape as in the following:
C#
DataShape ds = new DataShape();ds.AssociateWith( c => c.Orders.Where(p => p.ShippedDate != DateTime.Today));db.Shape = ds;var q = from c in db.Customers where c.City == "London" select c;foreach(Customer c in q) { foreach(Order o in c.Orders) {}} Visual Basic
Dim ds As DataShape = New DataShape()ds.AssociateWith(Of Customer)( _ Function(cust As Customer) From cust In db.Customers _ Where order.ShippedDate <> Today _ Select cust)db.Shape = dsDim londonCustomers = From cust In db.Customers _ Where cust.City = "London" _ Select custFor Each cust in londonCustomers For Each ord In cust.Orders … Next Next In the previous code, the inner foreach statement iterates just over the Orders that have been shipped today, because just such orders have been retrieved from the database.
It is important to notice two facts about the DataShape class:
After assigning a DataShape to a DataContext, the DataShape cannot be modified. Any LoadWith or AssociateWith method call on such a DataShape will return an error at run time.
