Your First SQL Server Database: Connect, Create, and Query in 5 Minutes

Setup is done. Now let’s actually touch SQL Server — connect, create a database, and prove it works with a real query. We’ll also cover exactly what each authentication option means and the handful of connection errors you’re statistically most likely to hit, so a wrong password doesn’t turn into twenty minutes of confusion.

Step 1: Connect

Open SSMS → Connect → enter your server name (e.g. localhost or localhostSQLEXPRESS) → choose an authentication mode.

For a Docker install, you’ll use SQL Server Authentication with username sa and the password you set in the MSSQL_SA_PASSWORD environment variable when you started the container.

Step 2: Create Your First Database

CREATE DATABASE TechCorpLite;
GO

USE TechCorpLite;
GO

SELECT 'Connected!' AS status, @@VERSION AS server_version;

Run it with F5. If you see a result grid with “Connected!” in it, you’re live. TechCorpLite is the database this entire tutorial series builds up, table by table — bookmark this one. By the end of Chapter 7’s capstone project, it’ll have authors, books, customers, and orders tables with real relationships between them.

What Just Happened, Visually

SSMS is just a client — it’s not the database itself. It sends your T-SQL over the network (TCP port 1433 by default) to the SQL Server engine, which parses, compiles, and executes it, then creates and manages the actual TechCorpLite database on disk. This client/server split matters later: the exact same T-SQL you type in SSMS is what any application (a web backend, a reporting tool, a Python script) sends over that same connection — SSMS has no special privileges the engine doesn’t also expose to any other client.

Exploring What You Just Created

Beyond just running a query, it’s worth seeing how SQL Server itself reports on its own structure — you’ll use these constantly:

-- List every database on this server
SELECT name, create_date FROM sys.databases;

-- Confirm which database your current session is using
SELECT DB_NAME() AS current_database;

-- Standard, cross-vendor way to inspect tables (empty for now — no tables yet)
SELECT * FROM INFORMATION_SCHEMA.TABLES;

sys.databases is a SQL-Server-specific system view; INFORMATION_SCHEMA is an ANSI-standard set of views that work similarly across SQL Server, PostgreSQL, and MySQL — useful to know if you ever move between database engines.

Fixing the Connection Errors You’ll Actually Hit

Key Takeaways

• SQL Server is the engine; SSMS/Azure Data Studio is just a client that talks to it over the network
• CREATE DATABASE makes a new, empty database; USE switches your session’s default context into it — without USE, unqualified table names resolve against the wrong database
• GO is a batch separator understood by SSMS/sqlcmd — it’s not T-SQL itself, and the server never sees it; it just tells the client tool where one batch of statements ends and the next begins
• Windows Authentication uses your OS login; SQL Server Authentication is a separate username/password the engine manages itself — you’ll need the latter for Docker, Linux, and most cloud setups