Troubleshooting [LINQ to SQL]
The following information exposes some issues you might encounter in your LINQ to SQL applications, and provides suggestions to avoid or otherwise reduce the effect of these issues.
Additional issues are addressed in Frequently Asked Questions.
If a query involves an in-memory collection and LINQ to SQL Table<TEntity>, the query might be executed in memory, depending on the order in which the two collections are specified. If the query must be executed in memory, then the data from the database table will need to be retrieved.
This approach is inefficient and could result in significant memory and processor usage. Try to avoid such multi-domain queries.
To specify an input file name, add the name to the command line as the input file. Including the file name in the connection string (using the /conn option) is not supported. For more information, see SqlMetal.exe (Code Generation Tool).
The Object Relational Designer creates a connection string in the app.config file of the project. In class library projects, the app.config file is not used. LINQ to SQL uses the Connection String provided in the design-time files. Changing the value in app.config does not change the database to which your application connects.
LINQ to SQL does not support or recognize cascade-delete operations. If you want to delete a row in a table that has constraints against it, you must do either of the following:
Set the ON DELETE CASCADE rule in the foreign-key constraint in the database.
Use your own code to first delete the child objects that prevent the parent object from being deleted.
Otherwise, a SqlException exception is thrown.
For more information, see How to: Delete Rows From the Database.
If you get the "Expression [expression] is not queryable; are you missing an assembly reference?" error, make sure of the following:
In the course of debugging a LINQ to SQL project, you might traverse an entity's relations. Doing so brings these items into the cache, and LINQ to SQL becomes aware of their presence. If you then try to execute Attach or InsertOnSubmit or a similar method that produces multiple rows that have the same key, a DuplicateKeyException is thrown.
Concatenation on operands mapped to [n]text and other [n][var]char is not supported. An exception is thrown for concatenation of strings mapped to the two different sets of types. For more information, see System.String Methods.
You must use identity members (IsPrimaryKey) when you use Take<TSource> or Skip<TSource> against a SQL Server 2000 database. The query must be against a single table (that is, not a join), or be a Distinct, Except, Intersect, or Union operation, and must not include a Concat<TSource> operation. For more information, see the "SQL Server 2000 Support" section in Standard Query Operator Translation.
This requirement does not apply to SQL Server 2005.
This exception is thrown when a column value is null in a GroupBy query that groups by a boolean expression, such as group x by (Phone==@phone). Because the expression is a boolean, the key is inferred to be boolean, not nullable boolean. When the translated comparison produces a null, an attempt is made to assign a nullable boolean to a boolean, and the exception is thrown.
To avoid this situation (assuming you want to treat nulls as false), use an approach such as the following:
GroupBy="(Phone != null) && (Phone=@Phone)"