ddl2cpp: duplicate #include for repeated FK targets, and money columns emit precision that violates SqlNumeric's own cap

[Yaraslaut]

Summary

Regenerating src/entities/ in the Lastrada repo against the 6.10 schema (pinned Lightweight version 0.20260625.0) surfaced two ddl2cpp regressions. Both broke the build; both were confirmed against the previous (correct) generation and, where relevant, against the live DB schema.

1. Duplicate #include lines when a table has multiple FKs to the same target

When a table has N foreign-key columns referencing the same target entity (e.g. several *_FK columns all pointing at the same lookup table), ddl2cpp emits #include "Target.hpp" once per FK column instead of deduplicating.

Confirmed as a regression: the previous generation had exactly one #include per referenced entity for the same tables.

Example (one entity header with 8 different FK columns to the same lookup table):

#include "SomeOtherEntity.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"
#include "LookupTable.hpp"

Scale: ~98 generated files affected in one regeneration pass, ~400 duplicate lines total. Worst case: one entity header had a single target's #include repeated 55 times (one FK per text field referencing that target).

Expected: one #include per distinct referenced entity, regardless of how many FK columns reference it.

2. SQL Server money columns mapped to a precision that violates SqlNumeric's own constraint

ddl2cpp maps money columns to Light::SqlNumeric<19, 4>. But SqlNumeric itself hard-caps precision:

// DataBinder/SqlNumeric.hpp
static_assert(Precision <= SQL_MAX_NUMERIC_LEN); // SQL_MAX_NUMERIC_LEN == 16

So every entity with a money column fails to compile:

error: static assertion failed due to requirement 'Precision <= 16'
note: in instantiation of template class 'Lightweight::SqlNumeric<19, 4>' requested here

Verified these columns are genuinely money in the DB DDL and have never changed type (checked migration history back to the earliest create table for each) — this is not a real schema change, ddl2cpp is simply choosing a precision that its own emitted type can't hold. The previous generation mapped the same columns to SqlNumeric<16, 4>, which compiled fine.

Scale: 14 generated files / 30 fields, all money-typed price/cost/total columns across several unrelated tables.

Expected: either cap the emitted precision at 16 for money (matching SQL_MAX_NUMERIC_LEN), or raise/remove the SqlNumeric precision cap if 19 digits is intentionally supported by the ODBC binding — but the two must agree so generated code compiles.

Possible third issue (lower confidence, only one instance found)

One varchar(100) column (confirmed via sys.columns against the live DB) has never changed type since the table was first created. It was correctly generated as Light::SqlAnsiString<100> previously, but came out as Light::SqlWideString<50> in this regeneration (wrong char width and wrong size). Only found this one instance while fixing consumer-code fallout, so it's possible this is isolated rather than systemic — flagging in case others hit the same thing on other columns.

Environment

• Lightweight version: 0.20260625.0 (vcpkg port, LASTRADA-Software/Lightweight v${VERSION} tag)
• ddl2cpp/dbtool built from the same tag via the tools vcpkg feature
• Target DB: SQL Server (ODBC), ddl2cpp run against a live 6.10 schema instance