Open nmccullar opened 8 years ago
The CONSTANTS table goes back to the beginning of the nBCR tool. All constants should be getting their values from this table, but unfortunately the table itself should be redesigned. Within the stored procedure, the constants really should be assigned ('doubled up') from the 'constants' table to avoid forcing large outer joins.
When there is time, CONSTANTS should be changed to a vertical table with only 3 columns and unrestricted rows, instead of the 40 or so columns and 1 row it has now.
The new table can be found in REHAB_Constants. All of CONSTANTS' variables have been placed in REHAB_Constants, and this will be the table that all constants are filled from. The value field "ConstantValue" holds the actual value, in nvarchar format. The intent is for this table to hold string variables as well as float and integer variables. Pulling from this table requires a CAST or CONVERT function, but nothing too goofy. If this becomes unwieldly, I'll separate into Constants_String, Constants_float, and Constants_date, etc.
DBO.COST_ESTIMATOR_WHOLE starts with a section defining constants, but also refers to table DBO.CONSTANTS.
Some constants defined in this section never get used. It's possible that some constants meant to be taken from DBO.CONSTANTS are getting superceded by constants defined locally.
Not necessarily a problem, but it's a little ugly, and it's possible that if we have some factor defined in CONSTANTS, and change it there, the change won't be applied in this section.