Skip to content

Installation — Database Setup

The NKO ERP uses two Entity Framework contexts against two separate databases, plus a third database for the Hangfire job store. Migrations must be applied per context — there is no single command that sets up both.

Context Connection string Database Migrations Project
NKO_DBEntities1 HrConnection NKO_DB 18 NKO.Lib/NKO.DataAccess
WarehouseDBContext WareConnection NKO_DB_Warehouse 5 NKO.Lib/NKO.Warehouse.DataAccess
(none — Hangfire manages its own schema) HangfireConnection e.g. NKO_Hangfire — —

There are no foreign keys between the two application databases. The only link is code: BGRN.TransfareToWarehouse writes rows into the warehouse database and flags the core record.

1. Create the databases

Create all three empty databases on the SQL Server instance, and make sure the account in the connection strings can create tables in each:

CREATE DATABASE NKO_DB;
CREATE DATABASE NKO_DB_Warehouse;
CREATE DATABASE NKO_Hangfire;

Hangfire builds its own schema on first start (PrepareSchemaIfNecessary = true), but it will not create the database — that must already exist or startup fails.

2. Fix the EF tooling version first

The pinned tool is older than the runtime — R5-2

NKO.Main/NKO.Main/.config/dotnet-tools.json pins dotnet-ef to 5.0.5, while every EF Core package in the solution is 6.0.15. Running the pinned tool prints EF's version warning:

The Entity Framework tools version '5.0.5' is older than that of the runtime '6.0.15'.
Update the tools for the latest features and bug fixes.

The tools are meant to be the same version as the EF Core runtime or newer; an older tool is not supported against a newer runtime and can fail outright. Either update the pin in dotnet-tools.json to 6.0.15, or install the tool globally at a matching version:

dotnet tool install --global dotnet-ef --version 6.0.15

With a local tool manifest:

cd NKO.Main/NKO.Main
dotnet tool restore

3. Apply the core migrations

Run from the startup project, naming the context explicitly:

cd NKO.Main/NKO.Main
dotnet ef database update --context NKO_DBEntities1

In the Visual Studio Package Manager Console, with NKO.Main as the startup project:

Update-Database -Context NKO_DBEntities1

This creates 146 tables — the 140 application tables (HR, payroll, procurement, finance, recruitment, training, administration) plus the six ASP.NET Identity tables (AspNetRoles, AspNetRoleClaims, AspNetUserClaims, AspNetUserLogins, AspNetUserRoles, AspNetUserTokens). The users table itself is ApplicationUsers, counted among the 140.

4. Apply the warehouse migrations

dotnet ef database update --context WarehouseDBContext

Update-Database -Context WarehouseDBContext

This creates the 21 warehouse tables, including the six under DbModel/Assets/ (Asset, AssetDetail, AssetPendingAmount, AssetsReturn, Computer, GRNReport) that are easy to miss when counting.

5. Verify

USE NKO_DB;            SELECT COUNT(*) FROM sys.tables;   -- expect 147 (146 + __EFMigrationsHistory)
USE NKO_DB_Warehouse;  SELECT COUNT(*) FROM sys.tables;   -- expect 22 (21 + __EFMigrationsHistory)

Both __EFMigrationsHistory tables should list every migration:

SELECT MigrationId FROM NKO_DB.dbo.__EFMigrationsHistory ORDER BY MigrationId;            -- 18 rows
SELECT MigrationId FROM NKO_DB_Warehouse.dbo.__EFMigrationsHistory ORDER BY MigrationId;  --  5 rows

What you will not have

The databases are empty — R5-1

Migrations create schema only. There is no seed data anywhere in the solution — zero HasData( calls, and no .sql script in the repository. After this step you have:

  • an empty ApplicationUsers table — nobody can sign in
  • no permission groups and no AppPermission rows, so even a manually created login would reach nothing
  • no reference data — no branches, departments, positions, leave types, calendars, donors or categories

Every one of those is normally created through the admin screens, which are themselves behind permission keys. First Run covers the two ways out of this.

Adding a migration later

Migrations belong to the data-access project, not the web project, so both --project and --startup-project are needed:

# core
dotnet ef migrations add <Name> \
  --context NKO_DBEntities1 \
  --project ../../NKO.Lib/NKO.DataAccess \
  --startup-project .

# warehouse
dotnet ef migrations add <Name> \
  --context WarehouseDBContext \
  --project ../../NKO.Lib/NKO.Warehouse.DataAccess \
  --startup-project .

Always pass --context. Without it EF cannot decide between the two and stops.

Next

  • First Run — starting the application and getting the first account in
  • Database — the schema itself: every table and column, with an ERD per entity