1st Normal Form-
- Break data into some smaller logical pieces i.e create separate columns for each small info like first name, middle name etc…
- Avoid repeating data and repeating groups i.e create Master table of records like city and use their IDs instead writing city names each time.
2nd Normal Form-
- All column in a table should depend on the full primary key and not the partial. Ex. A student is depend on standard and not on syllabus & subject but standard belongs to subject and syllabus. This normal form implemented via using a 1 to many relationship table.
3rd Normal Form-
- No Column in a table should not depend on the other column. Ex. Student marks Average column
Cannot insert the value NULL into column ‘ContextKey’, table ‘TestDb.dbo.__MigrationHistory’; column does not allow nulls. INSERT fails. The statement has been terminated.
Exception Type : System.Data.SqlClient.SqlException
We will get this error while upgrading EF 5.0 to EF 6.0
An EF5 Migration History table has the following structure:
CREATE TABLE [dbo].[__MigrationHistory]( [MigrationId] [nvarchar](255) NOT NULL, [Model] [varbinary](max) NOT NULL, [ProductVersion] [nvarchar](32) NOT NULL CONSTRAINT [PK_dbo.__MigrationHistory] PRIMARY KEY CLUSTERED ( [MigrationId] ASC ) )
When we upgrade EF 5.0 to EF 6.0 then it recreates the migration history table using the new structure, which looks like…
CREATE TABLE [dbo].[__MigrationHistory2] ( [MigrationId] [nvarchar](150) NOT NULL, [ContextKey] [nvarchar](300) NOT NULL, [Model] [varbinary](max) NOT NULL, [ProductVersion] [nvarchar](32) NOT NULL, CONSTRAINT [PK_dbo.__MigrationHistory2] PRIMARY KEY ([MigrationId], [ContextKey]) )
This table includes a new column ContextKey which is not null. So we are getting this error.
If you want to revert your database to the EF5 format in order to run a migration from EF5, just drop the ContextKey field and recreate the primary key:
ALTER TABLE dbo.__MigrationHistory DROP CONSTRAINT [PK_dbo.__MigrationHistory2] ALTER TABLE dbo.__MigrationHistory DROP COLUMN ContextKey ALTER TABLE dbo.__MigrationHistory ADD CONSTRAINT [PK_dbo.__MigrationHistory] PRIMARY KEY (MigrationId)
Programming is Easy…
A transaction is a single unit of work. If a transaction is successful, all of the data modifications made during the transaction are committed and become a permanent part of the database. If a transaction encounters errors and must be canceled or rolled back, then all of the data modifications are erased.
Transaction modes :-
Each individual statement is a transaction.
Each transaction is explicitly started with the BEGIN TRANSACTION statement and explicitly ended with a COMMIT or ROLLBACK statement.
A new transaction is implicitly started when the prior transaction completes, but each transaction is explicitly completed with a COMMIT or ROLLBACK statement.
Applicable only to multiple active result sets (MARS), a Transact-SQL explicit or implicit transaction that starts under a MARS session becomes a batch-scoped transaction. A batch-scoped transaction that is not committed or rolled back when a batch completes is automatically rolled back by SQL Server. Continue reading
SQL Server : JOINS are used to retrieve data from multiple tables. A SQL Server JOIN is performed whenever two or more tables are joined in a SQL statement.
There are 4 different types of SQL Server joins:
1) INNER JOIN -or- SIMPLE JOIN
2) LEFT JOIN -or- LEFT OUTER JOIN
3) RIGHT JOIN -or- RIGHT OUTER JOIN
4) FULL JOIN -or- FULL OUTER JOIN
5) SELF JOIN
6) CROSS JOIN
INNER JOIN:- INNER JOINS return all rows from multiple tables where the join condition is met.
INNER JOIN would return the records where table1 and table2 intersect.
SELECT COLUMNS FROM Table1 INNER JOIN Table2 ON Table1.column = Table2.column;
LEFT JOIN :- T his type of join returns all rows from the LEFT-hand table specified in the ON condition and only those rows from the other table where the joined fields are equal (join condition is met).
LEFT OUTER JOIN would return the all records from table1 and only those records from table2 that intersect with table1.
SELECT COLUMNS FROM Table1 LEFT JOIN Table2 ON Table1.column = Table2.column;
RIGHT JOIN :- This type of join returns all rows from the RIGHT-hand table specified in the ON condition and only those rows from the other table where the joined fields are equal (join condition is met).
RIGHT OUTER JOIN would return the all records from table2 and only those records from table1 that intersect with table2.
SELECT COLUMNS FROM Table1 RIGHT JOIN Table2 ON Table1.column = Table2.column;
FULL JOIN :- This type of join returns all rows from the LEFT-hand table and RIGHT-hand table with nulls in place where the join condition is not met.
FULL OUTER JOIN would return the all records from both table1 and table2.
SELECT COLUMNS FROM Table1 FULL JOIN Table2 ON Table1.column = Table2.column;
SELF JOIN :- A self join is simply when you join a table with itself. There is no SELF JOIN keyword, you just write an ordinary join where both tables involved in the join are the same table. One thing to notice is that when you are self joining it is necessary to use an alias for the table otherwise the table name would be ambiguous.
It is useful when you want to correlate pairs of rows from the same table, for example a parent – child relationship.
SELECT tbl1.column_name, tbl2.column_name... FROM table1 tbl1 JOIN table1 tbl2 ON tbl1.common_filed = tbl2.common_field;
Why we need a self join :- Suppose we have the following table – that is called employee. The employee table has 2 columns – employee_name and employee_location:-
Now, suppose we want to find out which employees are from the same location as the employee named A. In this example, that location would be India. Let’s assume – for the sake of our example – that we can not just directly search the table for people who live in A with a simple query like this (maybe because we don’t want to hardcode the city name) in the SQL query:
SELECT employee_name FROM employee WHERE employee_location = "A"
So, instead of a query like that what we could do is write a nested SQL query (basically a query within another query – which more commonly called a subquery) like this:
SELECT employee_name FROM employee WHERE employee_location in ( SELECT employee_location FROM employee WHERE employee_name = "A")
Using a subquery for such a simple question is inefficient. Is there a more efficient and elegant solution to this problem?
It turns out that there is a more efficient solution – we can use something called a self join. A self join is basically when a table is joined to itself.
SELECT E1.Employee_Name, E1.Employee_Location FROM Employees E1, Employees E2 WHERE E1.Employee_Location = E2.employee_Location AND E2.Employee_Name='A';
CROSS JOIN :- The SQL CROSS JOIN produces a result set which is the number of rows in the first table multiplied by the number of rows in the second table, if no WHERE clause is used along with CROSS JOIN. This kind of result is called as Cartesian Product.
If, WHERE clause is used with CROSS JOIN, it functions like an INNER JOIN.
An alternative way of achieving the same result is to use column names separated by commas after SELECT and mentioning the table names involved, after a FROM clause.
SELECT tbl1.column_name, tbl2.column_name... FROM table1 tbl1 CROSS JOIN table1 tbl2
Programming is Easy…