Troubleshoot problems encountered when using Entity Framework (version 4.3.1)

Here we will record the problems encountered in the previous use of Entity Framework (version 4.3.1.
Update a table with no primary key set
By default, EF cannot update, insert, or delete a table without a primary key. View the edmx file in xml format. You can see the following xml snippets in SSDL (I have defined a table tb_WithoutKey without a primary key ).
Copy codeThe Code is as follows:
<EntitySet Name = "tb_WithoutKey" EntityType = "TransferModel. Store. tb_WithoutKey" store: Type = "Tables" store: Schema = "dbo" store: Name = "tb_WithoutKey">
<DefiningQuery>
SELECT
[Tb_WithoutKey]. [ID] AS [ID],
[Tb_WithoutKey]. [Name] AS [Name]
FROM [dbo]. [tb_WithoutKey] AS [tb_WithoutKey]
</DefiningQuery>
</EntitySet>

I will add a table with a primary key for comparison. Similarly, in SSDL, we can see that the table with a primary key is defined as follows.
Copy codeThe Code is as follows:
<EntitySet Name = "tb_WithKey" EntityType = "TransferModel. Store. tb_WithKey" store: Type = "Tables" Schema = "dbo"/>

Modify the <EntitySet> node without a primary key according to the above node: Delete the <DefiningQuery> node, and change store: Schema = "dbo" to Schema = "dbo ". In this way, we can update, delete, and insert tables without primary keys.
The SSDL definition of a table without a primary key is actually more like a view. What I don't know is store: what is the role of this namespace? Why can't I just delete <DefiningQuery>, you also need to delete the store namespace of the Schema attribute. I still don't understand the above, but as a solution, it is indeed simple and feasible.
Change the default connection of Code-First
We know that when Code-First is used, we do not even need to write a connection string, but this default connection only recognizes the local SQL Express database, if you are using other databases or even non-Express versions of SQL Server, none of them will work.
If no database connection information is provided, EF creates a default defaultonfactory, which uses SqlConnectionFactory, then we can see its constructor through reflector as follows.
Public SqlConnectionFactory ()
{
This. _ baseConnectionString = @ "Data Source =. \ SQLEXPRESS; Integrated Security = True; MultipleActiveResultSets = True ";
}
Therefore, EF can only connect to SQL Express databases by default. SqlConnectionFactory provides a constructor overload that can specify the connection string and modify the default database connection. We can add the following nodes in the configuration file for configuration.
Copy codeThe Code is as follows:
<EntityFramework>
<Defaconnecticonnectionfactory type = "System. Data. Entity. Infrastructure. SqlConnectionFactory, EntityFramework">
<Parameters>
<Parameter value = "Data Source = heqichang-pc; Integrated Security = True; MultipleActiveResultSets = True"/>
</Parameters>
</Defaultonfactory>
</EntityFramework>

However, in any case, I think it is better to specify the connection string to develop and eliminate various uncontrollable factors.
Check string truncation errors
Sometimes the following errors may occur when EF is used.
 
The cause of this error is that the field length set in the database is smaller than the length of the new data you insert. However, if you know the reason, you need to know which field is out of the range, but it is difficult, and the information provided by EF is not clear. Of course, if there are few fields in the database, you can quickly filter them out, however, if there are many fields in the table, it will be troublesome. At this time, we can use the SQL Server Profiler tool that comes with SQL Server (this tool is not available for Express edition ).
Suppose I have a table tb_Test with the Name field in the table varchar (10 ). Enable Profiler before running the program with errors, and select the database you are connected to start monitoring. Finally, we can see the wrong SQL statement.
 
This tool can easily monitor database operations during EF running. Note that this tool will automatically identify the request from Entity Framework and then the specific SQL statement below.
The above is just a summary of the problems I encountered when I used EF in the last two weeks. In practice, it is definitely more than the problems I encountered above. You are welcome to raise more questions!