Module 2 Conclusion

Module 1 set up the stack this course builds on, Visual Studio 2026, ASP.NET Core Razor Pages on .NET 10, C#, and SQL Server 2025, and introduced VirtualBookShelf, the online bookstore project this course builds throughout. Module 2 then spent seven lessons on a single question: what is actually on the other end of a Razor Page's connection to a database, and how does data get from there onto a page a customer looks at? This page pulls those seven lessons together into one place before Module 3 moves into writing and running SQL statements directly.

It's worth noticing how little of this module actually required writing C# code. Four of the first five lessons, tables, database systems, access technologies, and SQL itself, are concepts a developer needs regardless of which programming language eventually implements them. Only once those concepts were in place did Lesson 6 and Lesson 7 turn to actual Razor Pages code, connecting to SQL Server 2025 and binding its data onto a page. That ordering wasn't incidental; writing a connection string or a LINQ query means little without first understanding what a table, a database system, and SQL itself actually are.

Each lesson in this module built directly on the one before it, and it's worth seeing that progression as a single line rather than seven separate topics:

• Lesson 1, Introduction to Database Concepts laid out the landscape: data is what the web is about, VirtualBookShelf's own Customer and Inventory tables are a small, concrete example of that, and this module's six objectives, repeated below, were set out as a map for everything that followed.
• Lesson 2, Table Structures in Relational Databases got specific about the table itself: rows, columns, declared data types, nullability, and the primary key that makes a row referable without ambiguity, all demonstrated directly against VirtualBookShelf's own Customer table.
• Lesson 3, Common Database Systems compared SQL Server 2025 against PostgreSQL, MySQL, Oracle Database, and Microsoft Access, and worked through the practical questions, expected users, storage, cost, efficiency, scalability, that actually decide which system a real project should use.
• Lesson 4, Data Access Components covered how an application actually reaches a database at all: ODBC and OLE DB as the low-level layer, classic ADO as the high-level layer this course leaves behind, and ADO.NET as the modern technology this course's own Razor Pages build on first.
• Lesson 5, Structured Query Language covered SQL itself: where it came from, how the ANSI standard has evolved since 1986, what SQL Server 2025 adds on top of that standard through T-SQL, and the client-server architecture every SQL statement ultimately travels through.
• Lesson 6, Setting Up Data Environment connected VirtualBookShelf to its SQL Server 2025 database for real, replacing the legacy Global.asa Data Environment model with a connection string in appsettings.json, read through IConfiguration, and used to open a SqlConnection directly.
• Lesson 7, Binding a Database to an Application Environment closed the loop: once a connection exists, Entity Framework Core maps query results onto C# objects automatically, and those objects bind directly to a Razor Page's view, HTML or JSON, without the page needing to know how the data was actually fetched.

Lesson 1 opened by asking what's on the other end of a database connection. By Lesson 7, that question has a complete, working answer, built one layer at a time.

Several lessons in this module started from content written for a much earlier version of this course, Visual InterDev, classic ASP, and in a few cases Microsoft Access rather than SQL Server, and it's worth naming the pattern across those corrections rather than letting each one stay a single, isolated fix.

The most consequential pattern was a direct contradiction, not simple staleness: Lesson 4 and Lesson 6 both originally described VirtualBookShelf as accessing a Microsoft Access database, virtualbook.mdb, despite Module 1, Lesson 3 and Lesson 3 of this module both already establishing SQL Server 2025 as the project's actual database, and explaining specifically why Access was ruled out. Catching that same contradiction twice, independently, in two different lessons said something real about where the legacy content came from: it predates the decision to use SQL Server at all.

A second pattern was architectural rather than factual: Global.asa and Visual InterDev's Data Environment designer, central to how the legacy version of Lesson 6 described connecting to a database, have no direct equivalent in ASP.NET Core. Rather than hunting for a renamed feature that doesn't exist, Lesson 6 replaced that model with appsettings.json, IConfiguration, and dependency injection, the framework's actual replacement for what Global.asa used to do, and Lesson 7 drew the same contrast again, between Visual InterDev's design-time, drag-and-drop data-binding controls and ASP.NET Core's explicit, code-based configuration.

A third, smaller pattern showed up in terminology: classic ADO, the COM-based VBScript API, and ADO.NET share a name but nothing else, a naming trap Lesson 1 flagged early and Lesson 4 and Lesson 6 both had to actively guard against, since older documentation and older course material almost always means classic ADO when it says "ADO" alone.

None of these corrections were cosmetic wording changes. Each one reflected a real gap between what the legacy course described and what this course's actual stack does, and each gap, once named clearly, pointed directly to the correct modern replacement rather than leaving a vague "this is now different" note in its place. That's the standard this module held itself to throughout: not simply updating a version number, but tracing exactly what changed architecturally and why.

Module 1, Lesson 3 first introduced VirtualBookShelf's two tables, and Lesson 2 of this module formally defined Customer in Transact-SQL. For a single reference point heading into Module 3, here are both tables together, Inventory written out the same way Lesson 2 wrote Customer:

CREATE TABLE dbo.Customer
(
    CustomerID  int IDENTITY(1,1) NOT NULL,
    FirstName   nvarchar(100) NOT NULL,
    LastName    nvarchar(100) NOT NULL,
    Email       nvarchar(255) NOT NULL,
    Phone       nvarchar(20) NULL,
    DateJoined  date NOT NULL DEFAULT (GETDATE()),

    CONSTRAINT PK_Customer PRIMARY KEY (CustomerID)
);

CREATE TABLE dbo.Inventory
(
    BookID          int IDENTITY(1,1) NOT NULL,
    Title           nvarchar(200) NOT NULL,
    Author          nvarchar(150) NOT NULL,
    ISBN            nvarchar(20) NOT NULL,
    Price           decimal(10,2) NOT NULL,
    QuantityOnHand  int NOT NULL DEFAULT (0),

    CONSTRAINT PK_Inventory PRIMARY KEY (BookID)
);

Neither table references the other yet. Module 1, Lesson 3 deliberately kept a sales or orders table out of this course's scope, so Customer and Inventory stay independent for now, exactly the two tables every lesson in this module has queried, updated, and bound against. If a later module ever adds an orders table, Lesson 2's own illustration already showed the shape that relationship would take: a foreign key column on the new table, referencing CustomerID or BookID directly, enforced by SQL Server rather than left to application code to check.

One query, finding every book currently in stock, appeared across this module in three different forms, and seeing all three side by side is a useful way to tie Lessons 4 through 7 together.

As plain SQL, the language every one of these technologies ultimately speaks, from Lesson 5:

SELECT Title, Author, Price FROM Inventory WHERE QuantityOnHand > 0;

As ADO.NET, the lower-level technology Lesson 4 introduced and Lesson 6 built a full connection around:

using (SqlConnection connection = new SqlConnection(connectionString))
{
    connection.Open();
    using (SqlCommand command = new SqlCommand(
        "SELECT Title, Author, Price FROM Inventory WHERE QuantityOnHand > 0", connection))
    {
        using (SqlDataReader reader = command.ExecuteReader())
        {
            while (reader.Read())
            {
                string title = reader.GetString(0);
            }
        }
    }
}

As Entity Framework Core, the technology Lesson 7 introduced for binding results onto application objects:

var booksInStock = context.Inventory
                          .Where(b => b.QuantityOnHand > 0)
                          .ToList();

All three send the same request to SQL Server 2025 and get back the same rows. What changes is how much of the work is explicit versus automatic: raw SQL is the request itself, ADO.NET wraps that request in an explicit connection, command, and reader, and EF Core generates the SQL and performs the object mapping automatically, built on the same ADO.NET and Microsoft.Data.SqlClient foundation underneath. Seeing the same operation at all three levels is the real payoff of this module's lesson order, ADO.NET first, EF Core second, rather than jumping straight to whichever one produces the least code.

Lesson 1 opened this module with six objectives. Each one now has a specific lesson, and a specific piece of VirtualBookShelf, behind it:

1. Identify table structures used in relational databases. Lesson 2 defined Customer in Transact-SQL, row by row and column by column, with its own PRIMARY KEY constraint.
2. Identify common database systems. Lesson 3 compared SQL Server 2025 against PostgreSQL, MySQL, Oracle Database, and Microsoft Access, and explained specifically why this course settled on SQL Server.
3. Recognize ADO.NET, Entity Framework Core, and ODBC as database access solutions. Lesson 4 placed all three, plus classic ADO and OLE DB, into a single, coherent picture of how an application actually reaches a database.
4. Explain what SQL is and what it does. Lesson 5 traced SQL back to IBM's 1974 System R project and showed how SQL Server 2025 implements and extends the ANSI standard through T-SQL.
5. Configure a connection string for a data source in a project. Lesson 6 put a working VirtualBookShelfConnection entry into appsettings.json and read it through IConfiguration.
6. Bind query results to a Razor Page using model binding and Tag Helpers. Lesson 7 used that connection, through Entity Framework Core, to map Inventory rows onto Book objects and bind them directly to a view.

Every objective Lesson 1 set out now has working code behind it, not just a definition. That's a deliberate design choice this module made throughout: each new idea, a table, a system, an access technology, SQL itself, a connection string, data binding, was demonstrated against VirtualBookShelf's own Customer and Inventory tables rather than a disconnected, generic example.

This module introduced a fair amount of terminology across seven lessons. A few terms are worth having in one place heading into Module 3:

• Primary key: the column, CustomerID or BookID, that guarantees every row can be referred to unambiguously. Introduced in Lesson 2.
• Foreign key: a column in one table that references another table's primary key, enforcing that a related row actually exists. Introduced in Lesson 2, through a standalone illustration rather than VirtualBookShelf's own schema, since Customer and Inventory don't reference each other yet.
• ODBC: a vendor-neutral standard for connecting to a database from any language or tool that implements it, still actively maintained today. Introduced in Lesson 4.
• ADO.NET: the .NET data access API this course teaches first, built around SqlConnection, SqlCommand, and SqlDataReader. Introduced in Lesson 4, connected to a real database in Lesson 6.
• Connection string: the single line of text naming a server, a database, and how to authenticate, that an application needs before it can reach SQL Server at all. Introduced in Lesson 6.
• Entity Framework Core (EF Core): the object-relational mapper this course introduces after ADO.NET, letting C# code query and update the database through objects like Book and Customer rather than raw SQL text. Introduced in Lesson 7.
• Parameterized query: a query where user-supplied values are passed separately from the SQL statement's own text, rather than concatenated into it, the mechanism that keeps a value a customer types from being interpreted as part of the SQL statement itself. Named explicitly in Lesson 5's and Lesson 7's architecture diagrams, and used by both ADO.NET and EF Core by default.

Do I need to memorize every SQL Server 2025 feature mentioned across this module? No. Features like system-versioned temporal tables, columnstore indexes, and the native VECTOR data type were introduced so you'd recognize them and know roughly what problem each one solves, not so you could write them from memory. VirtualBookShelf's own tables stay deliberately simple throughout this course; the advanced features matter far more at a production system's scale than at a teaching project's.

Why did this module wait until Lesson 6 before writing any C# code? Because the earlier lessons answered questions that have to come first: what a table actually is, which database system you're even targeting, and what technologies exist to reach it. Writing connection code before understanding what a table, a database system, or an access technology actually is would mean typing code without understanding what it does, which is exactly the gap this module's lesson order was built to avoid.

Which should I actually use going forward on VirtualBookShelf, ADO.NET or EF Core? Both remain valid, and this course uses both deliberately rather than treating one as obsolete. Lesson 7's own comparison put it directly: ADO.NET's explicit approach suits a complex or performance-sensitive query where full control matters, while EF Core is faster to write and easier to maintain for the everyday data access that makes up most of an application. Knowing both, and knowing which fits a given situation, is the actual skill this module built toward.

Is Microsoft Access or Visual InterDev still relevant to anything in this course? Not as technology this course builds on, no. Both came up repeatedly in this module, Access as one of the systems Lesson 3 compared SQL Server against, Visual InterDev as the legacy tool Lesson 6 and Lesson 7 both replaced with ASP.NET Core's configuration and dependency injection model, but purely as context for understanding why the modern stack is shaped the way it is. Nothing in Module 3 or beyond requires either one.

What's different about Module 3? Every lesson in this module was conceptual: understanding tables, systems, access technologies, SQL, connections, and binding, mostly without writing much code until the very end. Module 3 flips that: it's where this course gets hands-on, writing and running SQL statements directly against VirtualBookShelf's real, connected SQL Server 2025 database, building on every piece this module put in place.

Why does VirtualBookShelf still only have two tables after an entire module? Because two well-understood, correctly designed tables teach the underlying concepts, primary keys, data types, nullability, connections, binding, more clearly than a larger schema would at this stage. Module 1, Lesson 3 described later modules "enhancing" Customer and Inventory as new concepts arrive, rather than introducing an unrelated table for every new idea, so the schema grows only once there's a concrete reason for it to.

Does the order these seven lessons were taught in actually matter, or could they be studied in any order? The order matters more than it might appear. Lesson 2's table definitions are what Lesson 5's SQL statements query, Lesson 4's ADO.NET classes are what Lesson 6's connection code actually uses, and Lesson 6's connection string is exactly what Lesson 7's DbContext registration reads. Each lesson assumes the previous ones already happened, which is also why this conclusion page works as a single throughline rather than seven disconnected summaries.

Module 2 answered what's on the other end of a database connection: a relational database built from tables, running on a specific system, reachable through a specific set of technologies, speaking a specific language, connected through a specific configuration, and bound to a page through a specific pattern. Every piece of that answer now has working code behind it, tested against VirtualBookShelf's own Customer and Inventory tables.

Module 3 builds directly on all of it: writing SQL statements by hand, running them against VirtualBookShelf's connected SQL Server 2025 database, and seeing firsthand how the SELECT, INSERT, UPDATE, and DELETE statements this module introduced actually behave once they're no longer just examples in a lesson.

One last thing worth carrying forward explicitly: nothing in Module 3 introduces a new database, a new technology stack, or a new version of VirtualBookShelf's schema. The SQL Server 2025 instance Lesson 6 connected to, the Customer and Inventory tables Lesson 2 defined, and the ADO.NET and EF Core access patterns Lessons 4 and 7 built, are exactly what Module 3 writes SQL against. This module's real purpose was never just seven separate topics; it was building everything Module 3 now gets to assume already works.

Now try the quiz to test your understanding of these concepts.
Database Concepts - Quiz