When reviewing an item upgrade, distinguish the identifier of the resulting item from the identifier of the material/cost recipe used for that upgrade. The column names and storage format vary by branch, so identify them from the actual header/parser before editing values.
A synthetic relationship example
This is a teaching table, not a complete engine-ready proto export.
VNUM NAME REFINED_VNUM REFINE_SET
4100 Demo Sword 4101 20
4101 Demo Sword+1 0 0
Item reference: 4100 -> 4101
Recipe reference: item 4100 -> recipe 20The first question is whether item 4101 exists in the intended item data. The second is whether recipe 20 exists in the recipe data that this server build loads and has the intended materials/costs. An existing target item does not prove that the recipe is correct.
Investigation order
1. Record the exact item, attempted upgrade path and observed result.
2. Identify the target/recipe columns from the active format.
3. Check each reference in its own data source.
4. Confirm that the client and server use compatible versions of the changed item data.
5. Rebuild/import using your own workflow and test the intended NPC/scroll route on staging.
Do not reuse another project's recipe identifiers merely because their numbers look familiar. Preserve an unchanged copy and review any affected costs or materials before deployment.
What the free checker covers
M2City Proto Preflight checks target VNUM existence for recognised item headers. It does not inspect your database's recipe table, decide the intended cost or certify a whole upgrade route.
Reference
A community item-configuration tutorial describes these separate concepts. The relationship diagram and verification sequence here are original. Branch-specific NPC limits and column positions should be checked in your own implementation.