Hi,
Yes, your understanding is basically right. SQL error 305 on HANA is "single-row query returns more than one row", and in a CDS view it usually points to one thing: an association or join declared as to-one that, for some keys, finds more than one row in the target. HANA believes the cardinality you declare and builds the plan on top of it. When the data doesn't match, the ABAP documentation is very direct: "It is important that the cardinality specification matches the data in question. Otherwise, the result is undefined and can depend on the entries in the SELECT list."
That also explains why Sandbox and Dev are fine. The view is the same in every system, the data is not. It only breaks where a key really has duplicates in the target.
To be honest, I couldn't reproduce the 305 itself in my S/4HANA 2023 lab. But the "undefined result" part was easy to see. I joined MARA to MAKT on MATNR only, without the language, and declared MANY TO ONE. For a material with texts in 3 languages, COUNT(*) returned 1, because HANA dropped the join I had promised was to-one. Selecting MAKTX in the same query returned 3 rows. Without the cardinality, both gave 3.
SAP even ships a demo for this, DEMO_CDS_WRONG_CARDINALITY_1: an association from SCARR to SPFLI on CARRID only, with no cardinality written at all. For AC, AF and LH, counting per carrier gives 1 each, while reading CONNID through the same view gives 14 rows (LH alone has 12 flights).
Here is what I would check.
First, list every to-one association in your view and in the views below it. An association without an explicit cardinality is to-one by default ([0..1]), so the culprit may not even have a cardinality written.
Then compare each ON condition with the full key of the target. Text tables without the language and time-dependent data without a validity date are the classic cases.
Then, on the system where it fails, look for the duplicates directly. Use the target table and the fields of your ON condition:
SELECT matnr, COUNT(*) AS n
FROM makt
GROUP BY matnr
HAVING COUNT(*) > 1
If this returns rows, you found it. It's the only test that tells the truth, because it runs on the data that breaks.
And get the full error from ST22 (DBSQL_SQL_ERROR) or, if the call comes through OData, from /IWFND/ERROR_LOG. The statement in the dump helps to see which association path is involved.
The fix is one of two: complete the ON condition (language, validity date, a filter in the path expression), or declare the real cardinality (to-many) and deal with the extra rows on purpose.
If you can share the ON condition and the cardinality of the associations involved, I'm happy to take a look.
Bluesky
