Don't worry. Not everyone knows it...

Error 6002: The table/view 'AdventureWorks.dbo.BuildVersion' does not have a primary key defined. The key has been inferred and the definition was created as a read-only table/view. Explanation: The above warning is generated when you use Database first approach for Entity Framework model creation. Such warning appears due to entity key. Every Entity needs to have an entity key and when EF creates an entities, what it does is, it tries to find an primary key from the database and creates an entity key from that.  But it may be the case that few of the database objects doesn't have primary key defined. In that case, EF tries to infer a key based on your view or table's columns. So, here it becomes necessary to have at lease a non-null column in your database object.  It's just a warning, so nothing harmful here. But still if you need a solution to get rid of this warning, then it is posted by Hilmi Aric.

Many of you might have come across an issue of Auto incrementing while working with database products. Truly speaking, recently I also came across one silly problem and thought of sharing it here. Imagine that at some point of time, you might want to send your new data to a back-end database. If your application supplies the auto-increment values, then what will the database do? what if application receives duplicate values from different client applications? The answer is that these auto-increment values are never sent to the database because the auto-increment column in the database table will provide a value whenever a new row is added. After each new row is added, the back-end database table generates a new-increment number and then your application will query the database to get the newly created number. Your application will then update its primary key number to the values that came from the database. This means that all the foreign key references will need t...