Created Variables: Difference between revisions

Line 15:

== Testing... ==

Julie/Trish, let's track testing information for created_variables here... {{discussion}}

*“Transfer_Delay must be blanks instead of large negative values”

**Got it, I’ll fix that. Well, maybe we should decide if we want to keep to Ed’s std for missing transfer time. I could import/change the actual …3000… dates to nulls, I think. Should I try to change the actual data? That would also make it consistent with how new data will arrive.

***Sure, I agree that we change those dummy dates to null.

****I have created update query “1use_only_update_3000_transfer_dates_to_null” in centralized_front_end to update all records in centralized_data.mdb that have a 3000 transfer date and their corresponding transfer times to null. Since this will change much data it should probably be run by Pagasa on a master version of the data after creating a specific backup of the data. Trish, could you please coordinate with Pagasa once the newest front end that includes this is rolled out?

*Is 1/1/3000 9:45 your DEFAULT transf ready date time?

**It’s not mine, it’s how it shows in Ed’s data when I import it.

***OK, I am just surprise that there is time – I thought they are all zeroes.

****I just tried to find a record that has that transfer date time combination and can’t. Could you provide a D_ID?

===Calculation error due to dummy year and dummy times from blanks===

@@ Line 15: / Line 15: @@
 == Testing... ==
 Julie/Trish, let's track testing information for created_variables here... {{discussion}}
+*“Transfer_Delay  must be blanks instead of  large negative values”
+**Got it, I’ll fix that. Well, maybe we should decide if we want to keep to Ed’s std for missing transfer time. I could import/change the actual …3000… dates to nulls, I think. Should I try to change the actual data? That would also make it consistent with how new data will arrive.
+***Sure,  I agree that we change those dummy dates to null.
+****I have created update query “1use_only_update_3000_transfer_dates_to_null” in centralized_front_end to update all records in centralized_data.mdb that have a 3000 transfer date and their corresponding transfer times to null. Since this will change much data it should probably be run by Pagasa on a master version of the data after creating a specific backup of the data. Trish, could you please coordinate with Pagasa once the newest front end that includes this is rolled out?
+*Is 1/1/3000 9:45 your DEFAULT transf ready date time?
+**It’s not mine, it’s how it shows in Ed’s data when I import it.
+***OK, I am just surprise that there is time – I thought they are all zeroes.
+****I just tried to find a record that has that transfer date time combination and can’t. Could you provide a D_ID?
 ===Calculation error due to dummy year and dummy times from blanks===