From @jsfried: Got warning messages each time about no cut list trees, but the package must nonetheless be loaded else you can’t do a weighted mean analysis with grow-only as the baseline. The “a” disappeared after my load of the package. I warned Ryan that he might not have loaded 999 but he said that he did. I saved the project, exited BioSum, came back in, and low and behold, the “a” was back even though the 999 data is already loaded to PREPOST databases. That is undesirable and confusing behavior that I don’t recall occurring before we shifted away from Tree databases in the BioSumCalc folder. I can try to warn folks about it in the FVS chapter, but it would be nice if it behaved better.
From @lbross: This did break with moving all of the variant packages into one FVS_CutTree table. It's been a while, but I believe the previous code checked for the existence of the .MDB in the BioSumCalc folder to determine if the variant/package had been processed. Obviously this no longer works when all variant/packages are in the same database.
This display is managed by a 'BIOSUM_Append_YN' flag in the FVS_CASES table. When the page loads, BioSum checks to see if there are records in the FVS_CutTree table for each variant package. If there are not, it sets this flag to 'N' causing the 'a' to appear. Obviously this will always be the case for grow-only packages. When the append process runs, it sets this flag to 'Y' for each variant package so the 'a' goes away. But this only lasts for the duration of the BioSum session.
Updated loadvalues() method on FVS Out screen to check for records in PRE_FVS_SUMMARY instead of FVS_CutTree. Grow-only packages will never have records in FVS_CutTree.
From @jsfried: Got warning messages each time about no cut list trees, but the package must nonetheless be loaded else you can’t do a weighted mean analysis with grow-only as the baseline. The “a” disappeared after my load of the package. I warned Ryan that he might not have loaded 999 but he said that he did. I saved the project, exited BioSum, came back in, and low and behold, the “a” was back even though the 999 data is already loaded to PREPOST databases. That is undesirable and confusing behavior that I don’t recall occurring before we shifted away from Tree databases in the BioSumCalc folder. I can try to warn folks about it in the FVS chapter, but it would be nice if it behaved better.
From @lbross: This did break with moving all of the variant packages into one FVS_CutTree table. It's been a while, but I believe the previous code checked for the existence of the .MDB in the BioSumCalc folder to determine if the variant/package had been processed. Obviously this no longer works when all variant/packages are in the same database.
This display is managed by a 'BIOSUM_Append_YN' flag in the FVS_CASES table. When the page loads, BioSum checks to see if there are records in the FVS_CutTree table for each variant package. If there are not, it sets this flag to 'N' causing the 'a' to appear. Obviously this will always be the case for grow-only packages. When the append process runs, it sets this flag to 'Y' for each variant package so the 'a' goes away. But this only lasts for the duration of the BioSum session.