Answer
Referencing another custom field's value (via CF$) inside a different custom field's own select statement isn't reliably supported and is a likely cause of this exact 'no data found' error. Instead of depending on the other custom field's already-computed value, rewrite your select statement to independently derive whatever value you needed from that other field directly from the real underlying tables — for example, using a nested subquery against the actual source table/view the other custom field itself was computing its value from, rather than trying to read the other custom field's own CF$ column mid-select. This removes the cross-custom-field dependency entirely and resolves the error.