架设单机传奇后创建角色时持续提示“角色名已存在”或“账号角色重复”，即使使用全新名称仍无法解决，通常由数据库锁定、配置路径错误或服务端未正确读取账号数据导致。
首先确认账号是否真实创建成功。进入服务端目录MirServerShare，打开Account.mdb（需通过Access或MDB查看工具），检查Accounts表中是否存在刚注册的账号。若无记录，说明账号创建环节失败，角色自然无法关联，系统误判为重复。
其次检查DBC2000数据源配置。ODBC中Account数据源必须指向ShareAccount.mdb，HeroDB指向GuildBaseGuildBase.mdb。若路径错误或文件被占用，服务端无法写入新角色信息，每次尝试都会因查不到有效账号而回退到默认判断逻辑，触发重复提示。
第三，查看HeroInfo.txt与UserCmd.ini配置。MirServerMir200EnvirHeroInfo.txt定义角色创建规则，若其中AllowCreate被设为0，则禁止新建角色。UserCmd.ini中若存在重复的角色名校验脚本（如CHECKHERONAME），且未正确返回结果，也会导致死循环判断。
第四，清理客户端缓存。客户端User目录下存储本地角色缓存，若该目录存在同名角色记录，即使服务端无此角色，客户端仍会阻止提交。删除User文件夹（或重命名）后重新登录可强制刷新。
第五，验证DBSrc服务状态。DBSrc.exe负责处理角色创建请求，若未启动或崩溃，所有写库操作失效。观察MirServer主窗口，若DBSrc进程消失或日志报错“Can'topendatabase”，需重启服务端并确保mdb文件未被其他程序（如Access）打开。
第六，检查角色名过滤规则。某些版本在EnvirQuestDiarySystemQFunction-0.txt中设置角色名黑名单或正则校验，若脚本逻辑错误（如始终返回@Fail），会强制判定为无效或重复。临时清空相关脚本段可测试是否为此原因。
最后，确认服务端与客户端版本匹配。精简版客户端可能省略角色唯一性校验字段，导致协议不一致，服务端收不到完整创建包，反复拒绝请求。使用配套的完整客户端可排除协议偏差问题。
首先确认账号是否真实创建成功。进入服务端目录MirServerShare，打开Account.mdb（需通过Access或MDB查看工具），检查Accounts表中是否存在刚注册的账号。若无记录，说明账号创建环节失败，角色自然无法关联，系统误判为重复。
其次检查DBC2000数据源配置。ODBC中Account数据源必须指向ShareAccount.mdb，HeroDB指向GuildBaseGuildBase.mdb。若路径错误或文件被占用，服务端无法写入新角色信息，每次尝试都会因查不到有效账号而回退到默认判断逻辑，触发重复提示。
第三，查看HeroInfo.txt与UserCmd.ini配置。MirServerMir200EnvirHeroInfo.txt定义角色创建规则，若其中AllowCreate被设为0，则禁止新建角色。UserCmd.ini中若存在重复的角色名校验脚本（如CHECKHERONAME），且未正确返回结果，也会导致死循环判断。
第四，清理客户端缓存。客户端User目录下存储本地角色缓存，若该目录存在同名角色记录，即使服务端无此角色，客户端仍会阻止提交。删除User文件夹（或重命名）后重新登录可强制刷新。
第五，验证DBSrc服务状态。DBSrc.exe负责处理角色创建请求，若未启动或崩溃，所有写库操作失效。观察MirServer主窗口，若DBSrc进程消失或日志报错“Can'topendatabase”，需重启服务端并确保mdb文件未被其他程序（如Access）打开。
第六，检查角色名过滤规则。某些版本在EnvirQuestDiarySystemQFunction-0.txt中设置角色名黑名单或正则校验，若脚本逻辑错误（如始终返回@Fail），会强制判定为无效或重复。临时清空相关脚本段可测试是否为此原因。
最后，确认服务端与客户端版本匹配。精简版客户端可能省略角色唯一性校验字段，导致协议不一致，服务端收不到完整创建包，反复拒绝请求。使用配套的完整客户端可排除协议偏差问题。