传奇物品数据库加载失败Code-100的根源与修复操作

这个报错跟之前那种只报编号不报名字的情况不同，这次明确显示了“Idx:0 Name:命运之书”，后面跟着Code=-100。数据表里索引0存在，名字也是对的，编码没跳，跟备份文件一模一样，但引擎就是加载失败。这种情况往往不是数据内容的问题，而是数据库引擎读取时的环境或结构出了岔子。

Code=-100在传奇引擎的报错体系里通常指向数据库连接或读取时的底层错误。具体到物品库加载这一步，它表示DBC或者引擎在尝试读取StdItems.DB的时候，在索引0的位置拿到了数据，但在校验或解析过程中遇到了无法处理的状态。校验失败的原因可以是字段长度溢出、数据类型不匹配、或者文件头部的版本标记被改动过。

既然你确认了数据库内容和备份前一致，说明数据本身没坏。问题大概率出在DBC2000的配置环境上。DBC2000在读取DB文件时依赖系统注册表里的配置信息，包括每个字段的名称、类型、长度。如果注册表配置被其他程序修改了，或者DBC2000的版本升级后默认配置变了，即使DB文件内容没变，读取的时候也会因为字段定义不一致而报错。

具体到命运之书这一条，检查它的字段结构里有没有特别长的文本字段。比如物品描述、自定义属性字段，如果某个字段的长度超出了DBC2000当前配置的列宽限制，读取时就会截断或失败。而索引0是数据库的第一条记录，引擎加载时最先处理它，所以报错停在索引0，不代表只有索引0有问题，而是索引0卡住了后续的加载流程。

修复的第一步是重建DBC2000的字段配置。打开DBC2000，选中StdItems.DB，在菜单里找到Utilities -> Add/Delete Columns，把现有的字段列表截图保存，然后全部删除，再按照标准物品库的字段顺序重新添加一遍。字段名称和类型必须跟引擎要求的一致，标准字段包括Idx、Name、StdMode、Shape、Weight、Anicount、Source、Reserved、Looks、DuraMax、AC、AC2、MAC、MAC2、DC、DC2、MC、MC2、SC、SC2、Need、NeedLevel、Price、Stock。添加完成后保存，关闭DBC2000再重新打开加载，看报错是否消失。

第二步检查文件属性。DB文件如果被标记为“只读”或者存放在需要管理员权限的目录下，DBC2000读取时可能拿不到完整的文件句柄。右键StdItems.DB，属性里把只读勾掉，确保文件所在目录有写入权限。最好把整个数据库文件夹移到D盘根目录，避开系统盘的保护机制。

第三步用DBC2000自带的检查工具。在DBC2000里选中StdItems.DB，点击菜单里的Records -> Verify，它会扫描整个数据库的完整性和字段格式。如果Verify过程报错并指出具体位置，按提示修复那个位置的数据。如果Verify通过但加载依然失败，说明问题不在数据校验层面，而在引擎读取DB的接口层。

第四步检查引擎的数据库配置。GOM、GEE、BLUE等引擎在Mir200目录下都有一个!Setup.txt文件，里面有一行配置了数据库类型和路径，比如“DBName=StdItems.DB”。确认路径指向正确，文件名大小写跟实际文件一致。有些引擎对数据库文件的扩展名敏感，.DB和.db在Windows下不区分，但引擎内部可能区分，统一改成大写.DB。

第五步尝试导出导入重建数据库。在DBC2000里把StdItems.DB的全部数据导出为TXT格式，选择“Export As Text”并勾选“Include Field Names”。然后新建一个空的数据库文件，命名为StdItems.DB，把导出的文本重新导入。导入时确保字段顺序和类型匹配。这个方法能解决数据库文件头损坏或索引表错乱的问题，同时保留全部数据内容。

第六步如果以上都试过还报Code=-100，换一个DBC2000的版本。不同版本的DBC2000在处理字符串字段时的内存分配方式有差异，有些版本对中文支持不够好，命运之书里的中文字符可能被解析成多字节导致长度溢出。换用中文版或者更新的英文版试一下。

报错Code=-100虽然看着严重，但只要数据内容没丢，通过重建配置或重建文件的方式基本都能恢复。操作前把原StdItems.DB备份好，每一步做完都重新启动引擎测试，定位到具体哪一步解决问题，后面再遇到类似的就清楚怎么处理了。