As final testing stage for building , it issue surfaced with the `_hny.sql' script with the error message suggested one of the . It is not clear why this issue did not pop up in the build from the past since after some diagnosis from the group that there is a failure to relate the matches between HNY and mid_devdb tables from manual corrections and other matching methods
Using records we found in debugging process as a more concrete example:
job number 121190424 only shows up in the CORR_hny_matches.csv so the two hny_id (64645/992704, 64645/992703) matched with the job is not also linked to the other job number 1034857 which got matched with only one of the hny_id (64645/992703) through the bin and bbl matching logics.
This bug would then causing the logical incoherent in mapping the one-to-many relationships further downstream in and eventually causing table join to fail two places in the script
SELECT all_hny_units
FROM one_to_many b
WHERE a.job_number = b.job_number
and
SELECT classa_hnyaff
FROM one_to_many b
WHERE a.job_number = b.job_number
As final testing stage for building , it issue surfaced with the `_hny.sql' script with the error message suggested one of the . It is not clear why this issue did not pop up in the build from the past since after some diagnosis from the group that there is a failure to relate the matches between HNY and mid_devdb tables from manual corrections and other matching methods
Using records we found in debugging process as a more concrete example:
This bug would then causing the logical incoherent in mapping the one-to-many relationships further downstream in and eventually causing table join to fail two places in the script
and