简介：外聘教师管理系统是一套面向学校教务与人事管理场景的C# WinForms课程设计/小型管理系统源码，采用SQL Server数据库，围绕外聘教师信息维护、按院系/课程/姓名查询与统计、按代课数量和代课金级别计算工资、系部课程及代课金级别维护、登录权限与改密等模块展开，适合学习桌面端CRUD、统计查询和权限控制的学生与开发者参考。压缩包共97个文件，约35.47MB，包含26个cs源码、25张界面截图、多组resx/resources资源、dll与exe运行文件，以及mdf/ldf数据库、sln/csproj工程和配置文件，目录覆盖窗体设计、业务逻辑与数据库部分。已有437人学习下载，可用于对照完整工程理解窗体跳转、查询统计和普通用户只读权限的实现；包内附SQL2012数据库，修改数据库连接后即可运行调试。
1. 外聘教师管理系统：一份课酬表从 Excel 搬进 C# 加 SQL 的全过程
每到学期末，教务办最头疼的事情不是排课，而是核算外聘老师的课酬：课时数记录在教务系统的导出表里，职称系数保存在一张随手更新的 Excel 中，跨校区上课的补贴又记在另一个文档中，三份数据反复核对一遍，通常要花两天时间；一旦中间改了一门课，就得从头再算一遍。这套外聘教师管理系统就是把这套流程固化下来——用 C# WinForms 做录入和结算界面，用 SQL Server 存放教师档案、授课任务和结算单，点击“生成结算”后直接生成一张可以打印的课酬表。它适合三类人看：做课程设计或毕设、需要一套完整三层架构范例的在校开发者；需要给二级学院做小型内网工具的独立开发者；以及接手了这类历史项目、要在一堆DataGridView里加字段的维护者。下面按照我拆解项目的顺序展开，从解压后先看哪里，到核心的课酬计算怎样才算对，再到如何改成可配置规则。
2. 技术选型与目录结构：WinForms 加 ADO.NET 三层怎么落地
2.1 为什么是 C# WinForms + SQL Server，而不是 Web
先说结论：这套系统的使用场景是内网办公，用户数一只手数得过来，数据量在万级以内，所以选用 WinForms 不是技术保守，而是把维护成本压到最低。教务办只有两三台电脑，一台装数据库，其余装客户端；双击 exe 就能用，不需要 IIS，不需要域名，也不用担心浏览器版本兼容。DataGridView这种控件天生适合“一行一个老师、一列一个字段”的录入场景，改一个单元格就能修改，比 Web 表单提交后还要刷新页面方便得多。
数据库选 SQL Server 也是同一个思路：外聘教师、授课任务、结算单之间存在明确的主外键关系，用视图和存储过程把“按学期汇总课酬”这个动作下沉到数据库，客户端只负责展示结果。如果换成 SQLite，部署是更省事，但多台机器共享同一份数据时就会很麻烦；换成 MySQL 也能运行，只是这套代码里大量使用SqlParameter、SqlDataAdapter，迁移要修改的访问层代码不少，没必要。
代价也要说清楚，避免使用后才发现问题。WinForms 的界面风格比较陈旧，高分屏缩放下控件会模糊，需要在app.manifest里开启 DPI 感知；客户端更新时，需要把新的 exe 拷贝过去（后续可以考虑 ClickOnce）；并发能力很弱，两个人同时点击“结算”是唯一的真实并发点，这一点在第 5 章的避坑里还会遇到。放到这个项目上，这些代价都可以接受，但如果以后要支持外聘教师自己登录查询课酬，就应当切换到 Web，不应强行修改 WinForms。
2.2 从 .rar 解压后先看这四个目录
解压之后不要急着双击 sln 运行——先看清楚分层，修改代码时才知道该在哪里改。按照这个项目场景，合格开发一般会拆成 Model / DAL / BLL / UI 四层，加一个独立的数据库脚本目录。我把它整理成表格，方便对照：
| 路径 | 职责 | 修改频率 |
|---|---|---|
ETMS.sln | 解决方案入口，一般包含 4 个项目 | 低 |
DB/ETMS.sql | 建库建表、视图、存储过程、初始字典数据 | 中（加字段必改） |
Model/ | 实体类，如Teacher、TeachingTask、Settlement | 中 |
DAL/ | DbHelper+ 各表的XxxDAL，只写 SQL 和参数 | 高 |
BLL/ | 业务规则，课酬计算、学期状态校验都在这一层 | 高 |
UI/ | 窗体，FrmTeacher、FrmSettle、FrmMain | 高 |
App.config | 连接字符串、日志开关 | 部署时改 |
四个项目的引用关系是单向的：UI 引用 BLL，BLL 引用 DAL 和 Model，DAL 引用 Model，Model 谁都不引用。这条引用必须遵守——我见过不少同类项目，图省事在窗体里直接new SqlConnection连接数据库，结果连接字符串散落在二十多个文件里，换一台机器部署时要全局搜索并替换，那才是真正的麻烦。
判断一个 WinForms 项目分层是否清晰，有一个很快的检查方法：打开任意一个.cs窗体文件，搜索SqlConnection。如果搜到了，说明它正在绕过 BLL 直接访问数据库，这个项目的可维护性就要打折扣；如果整个 UI 目录一个都搜不到，说明分层是干净的，后续加字段只需要改 DAL 和 BLL。
2.3 连接字符串与 App.config 的正确写法
部署时最容易出问题的就是这一步。序里写死的连接字符串在新机器上一定会失败，所以要统一放到App.config的connectionStrings节点里，代码只按名字读取：
<?xml version="1.0" encoding="utf-8"?> <configuration> <connectionStrings> <!-- Data Source 用 机器名\实例名，本机默认实例可写 . 或 (local) --> <add name="ETMS" connectionString="Data Source=.;Initial Catalog=ETMS;User ID=etms_user;Password=******;Connect Timeout=15" providerName="System.Data.SqlClient" /> </connectionStrings> <appSettings> <!-- 结算时是否允许跨学期重算，默认关闭，防止误操作改历史账 --> <add key="AllowResettle" value="false" /> </appSettings> </configuration>读取的时候包一层，避免配置缺失时抛出的异常让人摸不着头脑：
// DAL/DbConfig.cs public static class DbConfig { private static string _conn; public static string Conn { get { if (_conn == null) { var setting = ConfigurationManager.ConnectionStrings["ETMS"]; if (setting == null) throw new ConfigurationErrorsException("App.config 中缺少名为 ETMS 的连接字符串"); _conn = setting.ConnectionString; } return _conn; } } // 单元测试或临时切库时用，正式运行不会走这里 public static void Override(string conn) { _conn = conn; } }参数里几个点要交代清楚。Data Source=.表示本机默认实例，如果安装的是命名实例（比如装了 Express 版），必须写成.\SQLEXPRESS；Initial Catalog是库名，改名了这里要同步修改；Connect Timeout=15是连接超时，默认也是 15 秒，显式写出来是为了让运维看到；认证方式建议用 SQL 账号而不是 Windows 集成认证，因为教务办的机器不一定会加入域，Integrated Security=True在跨机器调用时反而会变成新的麻烦。AllowResettle这个开关在后续结算逻辑里会用到，用来防止历史学期被重复计算。
3. 数据库设计：教师、授课任务、结算单三张主表怎么串
3.1 建表脚本与字段设计
整个系统的数据模型其实是一条链：一个教师在一个学期里承担若干门课的授课任务，学期结束时把所有任务按职称系数折算成课酬，写进结算单。所以核心是五张表加两张字典表。我把关键部分的建表语句贴出来，字段类型是血泪经验调过的：
-- 职称字典：系数决定课酬倍率，放在表里而不是写死在代码里 CREATE TABLE Title ( TitleId INT IDENTITY(1,1) PRIMARY KEY, TitleName NVARCHAR(20) NOT NULL, -- 助教/讲师/副教授/教授 Coefficient DECIMAL(4,2) NOT NULL, -- 1.00 / 1.20 / 1.50 / 1.80 IsActive BIT NOT NULL DEFAULT(1) ); CREATE TABLE Teacher ( TeacherId INT IDENTITY(1,1) PRIMARY KEY, TeacherNo VARCHAR(20) NOT NULL, -- 工号，唯一，纯 ASCII 用 varchar TeacherName NVARCHAR(30) NOT NULL, -- 姓名必须 nvarchar，否则生僻字乱码 TitleId INT NOT NULL, DeptName NVARCHAR(50) NULL, -- 外聘教师可能不属于任何院系 Phone VARCHAR(20) NULL, BankAccount VARCHAR(32) NULL, Status TINYINT NOT NULL DEFAULT(1), -- 1 在职 0 停用 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Teacher_No UNIQUE (TeacherNo), CONSTRAINT FK_Teacher_Title FOREIGN KEY (TitleId) REFERENCES Title(TitleId) ); -- 授课任务：一门课一个外聘老师一条，同一老师同一课程可多条（不同班级） CREATE TABLE TeachingTask ( TaskId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, CourseName NVARCHAR(60) NOT NULL, ClassName NVARCHAR(60) NULL, Campus NVARCHAR(20) NULL, -- 校区，跨校区有补贴 Hours DECIMAL(6,1) NOT NULL, -- 允许 0.5 学时 StudentCount INT NULL, CONSTRAINT FK_Task_Teacher FOREIGN KEY (TeacherId) REFERENCES Teacher(TeacherId) ); -- 结算单：一个学期一个老师一条，TotalAmount 是最终发放金额 CREATE TABLE Settlement ( SettleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, TeacherId INT NOT NULL, TotalHours DECIMAL(8,1) NOT NULL, TotalAmount DECIMAL(12,2) NOT NULL, Status TINYINT NOT NULL DEFAULT(0), -- 0 草稿 1 已确认 Operator NVARCHAR(30) NULL, CreateTime DATETIME NOT NULL DEFAULT(GETDATE()), CONSTRAINT UQ_Settle UNIQUE (TermId, TeacherId) -- 唯一约束是幂等的最后一道锁 );这段脚本里有三个决定必须说明。第一，TeacherName用NVARCHAR而TeacherNo用VARCHAR，这是有意的：工号是数字和字母，varchar节省空间且索引更小；姓名里会出现生僻字，varchar在非 Unicode 排序规则下直接存成问号，那就是数据事故。第二，Hours用DECIMAL(6,1)而不是INT，教务这边确实存在 1.5 学时、0.5 学时的情况，用整数会出现“明明 24 学时算出来 23”的玄学问题。第三，UQ_Settle这个唯一约束看起来可有可无，实际上是并发重复结算的最后一道防线，第 5 章会展开讲它为什么比代码里的if判断更可靠。
3.2 视图与存储过程：把课酬汇总下沉到数据库
课酬的计算口径是：课时 × 职称系数 × 单位课时费 + 跨校区补贴。这个公式一旦写死在 C# 里，每次调整口径都要重新编译发版；放到存储过程里，只改脚本就行。我先建一个明细视图，把任务、教师、职称串起来：
CREATE VIEW vw_TaskDetail AS SELECT t.TaskId, t.TermId, t.TeacherId, te.TeacherNo, te.TeacherName, ti.TitleName, ti.Coefficient, t.CourseName, t.ClassName, t.Campus, t.Hours, -- 跨校区补贴按每学时固定 10 元，放到配置表更好，这里先内联 CASE WHEN t.Campus IS NOT NULL AND t.Campus <> N'主校区' THEN 10.00 ELSE 0.00 END AS CampusSubsidy FROM TeachingTask t JOIN Teacher te ON te.TeacherId = t.TeacherId JOIN Title ti ON ti.TitleId = te.TitleId;结算存储过程我一般写成“先清理草稿再重算”，保证多次执行的最终结果一致：
CREATE PROCEDURE usp_CalcSettlement @TermId INT, @Operator NVARCHAR(30) AS BEGIN SET NOCOUNT ON; BEGIN TRY BEGIN TRAN; -- 1. 已确认的单据不允许重算，直接抛出业务错误 IF EXISTS (SELECT 1 FROM Settlement WHERE TermId = @TermId AND Status = 1) BEGIN RAISERROR(N'该学期已有确认的结算单，请先反确认', 16, 1); END -- 2. 清掉旧草稿，实现幂等 DELETE FROM Settlement WHERE TermId = @TermId AND Status = 0; -- 3. 按教师汇总，用 ROUND 显式指定四舍五入方式 INSERT INTO Settlement (TermId, TeacherId, TotalHours, TotalAmount, Status, Operator) SELECT @TermId, d.TeacherId, SUM(d.Hours), SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) + d.CampusSubsidy * d.Hours), 0, @Operator FROM vw_TaskDetail d WHERE d.TermId = @TermId GROUP BY d.TeacherId; COMMIT; END TRY BEGIN CATCH IF @@TRANCOUNT > 0 ROLLBACK; THROW; -- 把原始错误抛给上层，不要在存储过程里吞掉 END CATCH END逐段看：@TermId是学期主键，UI 上选哪一学期就传哪个；@Operator记录操作人，出问题时能追到是谁点击的。第 1 步的RAISERROR用的是THROW之外的业务报错方式，16表示可以捕获的用户级错误。第 3 步的SUM(ROUND(...))是先按单条任务四舍五入再汇总，而不是汇总完再四舍五入，这两种算法在 3 条以上任务时会差出几分钱，财务那边对不上账的根源往往就在这里。100.0是单位课时费，实际部署时应当从配置表读取，我这里是简化版。
THROW而不吞异常这一点值得单独说。很多同类的存储过程在CATCH里只写SELECT ERROR_MESSAGE()然后RETURN，调用方拿到的是“执行成功但没数据”，排查时完全是黑匣子。用THROW把原始错误码和消息抛回 ADO.NET，C# 侧catch (SqlException ex)能直接拿到错误号和文本，定位快得多。
3.3 索引与数据量预估：别等到卡了才加
这套系统的真实数据量大概是：教师几百条，每学期授课任务两三千条，结算单几百条。这个量级下，全表扫描也不会明显卡顿，但该建的索引还是要建，因为它的成本几乎为零：
-- 结算时按学期 + 教师聚合，这个是覆盖面最广的 CREATE NONCLUSTERED INDEX IX_Task_Term_Teacher ON TeachingTask (TermId, TeacherId) INCLUDE (Hours, Campus); -- 教师列表按状态筛选 + 按工号排序 CREATE NONCLUSTERED INDEX IX_Teacher_Status_No ON Teacher (Status, TeacherNo);INCLUDE里放Hours和Campus是为了让结算查询走覆盖索引，不用回表。这个技巧在几千行数据上感知不到，但如果哪天有院系把历史五年的数据一起导进来，就是能不能接受的区别。
字段类型上还有两个常见误用要提醒：金额一律DECIMAL(12,2)，不要用MONEY，MONEY在参与复杂表达式时精度行为不直观，而且各家数据库迁移时不兼容；日期用DATETIME2比DATETIME精度更高，但这个项目里全是“某年某月某日”的业务日期，用DATE其实更合适，可以省掉一串“2024-03-01 00:00:00.000 和 2024-03-01 23:59:59.997 算不算同一天”的扯皮。
4. 核心模块拆解：教师档案与课酬结算的完整链路
4.1 DAL 层的 DbHelper：一个类挡住所有注入和连接泄漏
数据访问层如果只允许保留一个类，那一定是DbHelper。它要做三件事：从配置读取连接串、参数化传入 SQL、用using保证连接归还连接池。写得好，整个项目的 SQL 注入风险和连接泄漏风险就都控制在这里了：
public static class DbHelper { // 查询：返回 DataTable，适合直接绑定 DataGridView public static DataTable Query(string sql, params SqlParameter[] ps) { var dt = new DataTable(); using (var conn = new SqlConnection(DbConfig.Conn)) using (var cmd = new SqlCommand(sql, conn)) using (var da = new SqlDataAdapter(cmd)) { if (ps != null && ps.Length > 0) cmd.Parameters.AddRange(ps); da.Fill(dt); // Fill 内部自动 Open/Close，不用手写 } return dt; } // 增删改：返回受影响行数，调用方据此判断是否成功 public static int Execute(string sql, params SqlParameter[] ps) { using (var conn = new SqlConnection(DbConfig.Conn)) using (var cmd = new SqlCommand(sql, conn)) { if (ps != null && ps.Length > 0) cmd.Parameters.AddRange(ps); conn.Open(); return cmd.ExecuteNonQuery(); } } // 事务版：结算这种多步操作必须用同一个连接 public static int ExecuteTran(Action<SqlConnection, SqlTransaction> work) { using (var conn = new SqlConnection(DbConfig.Conn)) { conn.Open(); using (var tran = conn.BeginTransaction()) { try { work(conn, tran); tran.Commit(); return 1; } catch { tran.Rollback(); throw; } } } } }三个方法的区别在于使用场景：Query用SqlDataAdapter.Fill，内部会自己打开和关闭连接，适合列表页；Execute手动Open，返回受影响行数，适合单条保存；ExecuteTran把一个委托作为工作单元传进来，连接和事务都由它管理，适合结算。参数统一用params SqlParameter[]，调用方写new SqlParameter("@TeacherId", id)，这样即使参数值来自界面输入框，也永远走参数化，不会被拼成 SQL 字符串。这是防注入的根本手段，不要靠手动转义引号。
一个细节：Query里没写conn.Open()，因为Fill会按需打开；但如果写成先Open再Fill，用完忘了Close，连接池几十次就被耗尽，表现出来就是“用一会儿就提示超时”，这种问题最难排查。using是后悔药，写的时候多敲两行，比事后排查省一整天。
4.2 教师信息增删改查：DataGridView 绑定的正确姿势
教师管理窗体是整个系统的入口，也是最容易写出 bug 的地方。常见的错误做法是把界面上的值逐个从DataGridView单元格里读出来拼 SQL，代码又长又容易漏字段。正确做法是绑定DataTable，让控件和内存表同步，保存时只遍历有变化的行：
private DataTable _dtTeacher; private void LoadTeachers(string keyword) { // 关键字过滤用参数化 LIKE，不要拼字符串 string sql = @"SELECT TeacherId, TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status FROM Teacher WHERE (@kw = '' OR TeacherNo LIKE @kw OR TeacherName LIKE @kw) ORDER BY TeacherNo"; _dtTeacher = DbHelper.Query(sql, new SqlParameter("@kw", "%" + keyword + "%")); gridTeacher.DataSource = _dtTeacher; } private void btnSave_Click(object sender, EventArgs e) { gridTeacher.EndEdit(); // 必须显式结束编辑，否则最后一个单元格的值丢失 foreach (DataRow row in _dtTeacher.Rows) { if (row.RowState == DataRowState.Unchanged) continue; if (row.RowState == DataRowState.Added) { DbHelper.Execute( @"INSERT INTO Teacher (TeacherNo, TeacherName, TitleId, DeptName, Phone, BankAccount, Status) VALUES (@no, @name, @title, @dept, @phone, @bank, @status)", new SqlParameter("@no", row["TeacherNo"]), new SqlParameter("@name", row["TeacherName"]), new SqlParameter("@title", row["TitleId"]), new SqlParameter("@dept", (object)row["DeptName"] ?? DBNull.Value), new SqlParameter("@phone", (object)row["Phone"] ?? DBNull.Value), new SqlParameter("@bank", (object)row["BankAccount"] ?? DBNull.Value), new SqlParameter("@status", row["Status"])); } else if (row.RowState == DataRowState.Modified) { DbHelper.Execute( @"UPDATE Teacher SET TeacherName = @name, TitleId = @title, DeptName = @dept, Phone = @phone, BankAccount = @bank, Status = @status WHERE TeacherId = @id", new SqlParameter("@name", row["TeacherName"]), new SqlParameter("@title", row["TitleId"]), new SqlParameter("@dept", (object)row["DeptName"] ?? DBNull.Value), new SqlParameter("@phone", (object)row["Phone"] ?? DBNull.Value), new SqlParameter("@bank", (object)row["BankAccount"] ?? DBNull.Value), new SqlParameter("@status", row["Status"]), new SqlParameter("@id", row["TeacherId"])); } } LoadTeachers(txtKeyword.Text); // 重新拉一遍，让自增主键回到前台 }这段代码的关键点有四个。EndEdit()不能省，DataGridView在单元格仍处于编辑态时，用户刚输入的值还在编辑控件里，没有提交到DataTable，漏掉这一步的表现是“我明明改了姓名，保存后没变”，非常容易被误判成数据库没提交。row.RowState用来跳过未修改的行，几百条教师挨个UPDATE一遍虽然也能跑，但白白产生几百条事务日志。WorkerNo没有出现在UPDATE的SET子句里，因为工号是唯一键，改了会影响历史结算单的追溯，业务上就不允许改。(object)row["DeptName"] ?? DBNull.Value是处理 NULL 的固定写法，直接传null给SqlParameter在部分版本上会抛参数异常。
4.3 课酬结算：从点击按钮到写入结算单的完整链路
结算窗体的逻辑分三步：选学期、预览、确认。预览不落库，确认才调存储过程。这里我用ExecuteTran把“调存储过程 + 写操作日志”包在一个事务里：
public class SettleService { public DataTable Preview(int termId) { // 预览直接算，不写 Settlement 表，避免用户点一次就脏一次数据 string sql = @" SELECT d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName, SUM(d.Hours) AS TotalHours, SUM(ROUND(d.Hours * d.Coefficient * 100.0, 2) + d.CampusSubsidy * d.Hours) AS TotalAmount FROM vw_TaskDetail d WHERE d.TermId = @termId GROUP BY d.TeacherId, d.TeacherNo, d.TeacherName, d.TitleName ORDER BY d.TeacherNo"; return DbHelper.Query(sql, new SqlParameter("@termId", termId)); } public void Confirm(int termId, string op) { DbHelper.ExecuteTran((conn, tran) => { using (var cmd = new SqlCommand("usp_CalcSettlement", conn, tran)) { cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.AddWithValue("@TermId", termId); cmd.Parameters.AddWithValue("@Operator", op); cmd.CommandTimeout = 60; // 结算走全量聚合，默认 30 秒可能不够 cmd.ExecuteNonQuery(); } // 操作日志和数据变更同一个事务，要么都成功要么都不留 using (var log = new SqlCommand( "INSERT INTO OperLog (Module, RefId, OperUser, OperTime) VALUES (N'结算', @t, @u, GETDATE())", conn, tran)) { log.Parameters.AddWithValue("@t", termId); log.Parameters.AddWithValue("@u", op); log.ExecuteNonQuery(); } }); } }Preview和Confirm用的是同一套计算口径，区别只在于前者不落库。这样安排的好处是，用户在预览里看到 3280.50 元，点确认后存进去的也一定是 3280.50 元，不会因为两处公式写法有细微差异而对不上。有些项目预览在一个 SQL 里算，确认在另一个存储过程里算，结果两边差几分钱，查起来极其痛苦。
AddWithValue这个写法有争议：它让 SQL Server 自己推断参数类型，对于DECIMAL有时会推断成FLOAT，引发隐式转换。稳妥一点，写成new SqlParameter("@TermId", SqlDbType.Int) { Value = termId }。我在维护旧项目时遇到过一次，@termId被推断成nvarchar，导致索引失效、查询从 0.1 秒变成 8 秒，改回显式类型就好了。
CommandTimeout也别忽略。默认 30 秒，学期数据多的时候聚合会超时，表现出来是“结算点了没反应，过了一会儿弹出超时错误”，但此时存储过程可能已经执行完了，用户再点一次就是重复结算。把超时设长一点，同时靠存储过程里的DELETE + INSERT和唯一约束兜底，这才是双保险。
5. 踩坑排查：跑不起来、连不上库、算错钱的那几个坑
5.1 环境和连接类：环境问题不是配置问题
现象一：双击 sln 打开后，右键生成失败，提示“找不到目标框架 .NETFramework,Version=v4.7.2”。原因：这套项目用的是 .NET Framework，不是 .NET Core / .NET 8，新机器上只装了运行时没装开发者包，或者项目重定向到了本机没有的版本。 解决：在项目属性里把“目标框架”改成机器上已有的版本（比如 4.6.1 或 4.8），改完顺手把packages.config里引用的System.Data.SqlClient之类检查一遍；或者直接安装对应版本的 Developer Pack。不要图省事改成 .NET 8，那要动整个 csproj 的格式，改造成本远大于装个包。
现象二：登录时报“在与 SQL Server 建立连接时出现与网络相关的或特定于实例的错误”。原因：最常见的是实例名写错，其次是 SQL Server Browser 服务没启动，再次是 TCP/IP 协议没启用。Express 版默认是命名实例，连接串写成.一定连不上。 解决：打开services.msc确认SQL Server (SQLEXPRESS)和SQL Server Browser两个服务都在运行；在 SQL Server 配置管理器里把TCP/IP启用；连接串改成Data Source=.\SQLEXPRESS再试。如果是在另一台机器上连，还要在防火墙里放行 1433 端口（命名实例是动态端口，开 Browser 更省事）。
现象三：Keeps asking 登录失败，提示“用户 'sa' 登录失败”。原因：装库的时候选了 Windows 身份验证模式，sa账号被禁用，而连接串里写的是User ID=sa。 解决：用 Windows 认证登进 SSMS，在服务器属性里改成“混合模式”，启用sa并设密码；更好的做法是新建一个只有ETMS库读写权限的专用账号etms_user，客户端用它连，避免用超级管理员账号跑业务系统。
5.2 数据与计算类：错在第四位小数上
现象四：两个人先后点“结算”，Settlement 表里同一学期同一教师出现两条记录。原因：代码里先SELECT判断有没有结算过，再INSERT，判断和写入之间有窗口期；两个客户端同时通过判断，就都插进去了。 解决：靠数据库的唯一约束UQ_Settle (TermId, TeacherId)兜底，插入冲突时捕获SqlException的 2627 错误号，提示“该教师本学期已结算”。代码里的if判断只能防误操作，防不了并发，别把它当锁用。
现象五：课酬总额和财务手算的差几分钱。原因：一是用了double参与计算，浮点数在二进制下无法精确表示 0.1 这类小数；二是Math.Round默认是银行家舍入，2.345 会变成 2.34 而不是 2.35。 解决：金额全链路用decimal，SQL 端用DECIMAL(12,2)；四舍五入显式写Math.Round(x, 2, MidpointRounding.AwayFromZero)，SQL 端ROUND(x, 2)默认就是四舍五入，但要确认没有混入double类型的计算列。改完后拿三条边界数据（1.005、2.675、0.125）跑一遍验证。
现象六：教师姓名存进去变成问号“??”，或者生僻字变成方框。原因：TeacherName字段建成了VARCHAR，插入时又没加N前缀，中文字符在非 Unicode 排序规则下被截断。 解决：字段类型改NVARCHAR，SQL 里的字符串字面量统一加N''前缀，C# 侧SqlParameter用SqlDbType.NVarChar。改的时候注意已有数据要先备份，ALTER COLUMN之后再补一遍数据。
6. 二次开发：把课酬规则和导出做成能改的
接手这类项目，最值钱的改造不是加界面，而是把“算钱”这件事从代码里挪出来。当前版本的单位课时费100.0还内联在存储过程里，职称系数虽然进了Title表，但改一次系数会把历史学期一起改掉。我的做法是加一张带生效区间的规则表：
CREATE TABLE PayRule ( RuleId INT IDENTITY(1,1) PRIMARY KEY, TermId INT NOT NULL, -- 按学期生效，历史账不受影响 UnitPrice DECIMAL(8,2) NOT NULL, -- 单位课时费 CampusFee DECIMAL(8,2) NOT NULL, -- 跨校区每学时补贴 CreateTime DATETIME NOT NULL DEFAULT(GETDATE()) );结算存储过程里把两个硬编码值替换成从PayRule按@TermId查出来的变量，查不到就RAISERROR提示“该学期未配置课酬规则”。这样一来，新学期开学只用在界面上录一条规则，不用重新编译发布。改完必须验证：先造 3 条授课任务（1.5 学时讲师、2 学时副教授、跨校区 1 学时），手算三遍总额，再和系统跑出来的对比，一分不差才算通过。
第二个改造是导出。教务那边最终要的是 Excel，别用DataGridView直接打印，加个导出按钮，用 NPOI 写 xlsx 三十行代码就够，或者退一步先导 CSV——注意 CSV 用 UTF-8 带 BOM，否则 Excel 打开中文又是乱码，这个坑我踩过不止一次。导出的列顺序和表头要和财务给的模板严格一致，别自作主张加字段。
那以后我每次改结算逻辑，都会强制走一遍“三组边界数据手算 + 存储过程重复执行两次看结果是否一致”的流程。课酬这种涉及金额的计算，一次算错就要重新解释，宁可多花二十分钟验证。希望这些拆解能帮你把这套系统顺利跑起来，也少踩几个我踩过的坑。
本文还有配套的精品资源，点击获取
