County codes in related tables not populated

[KCI-Ablowers]

While reviewing the KCI_1 production version, Brent and I noticed that the county codes (CNTY_CODE) in the related tables are not populated. I am not sure if this was ever addressed during testing or moves from dev to prod. @brentreeves75 said this should be populated based on the related features code.

[kerrymcmahon]

Do you all want me to update these? I just need the connection to KCI DEV. I think I might have it already.

[ladejobi]

@kerrymcmahon not yet. What's the impact of the update on the SWMFAC widget.

[KCI-Ablowers]

@johnshiu Is this something that could be built into the ETL at this point?

@kerrymcmahon & @ladejobi I am not sure if this will cause any issues with the SWMFAC Widget but this should most likely (and hopefully) be taken care of during the Field-to-Source ETL.

[johnshiu]

Yes, this is something that can be built into the ETL. However, since this KCI_1 version is already committed, we may need to update the county codes manually in the version.

Hopefully, this will be rather easy if all the county codes are the same, as we should be able to look at the newest entries in each related table and fill them in with the same values.

[KCI-Ablowers]

I am going to sit down with @impittman tomorrow to do the rec and post. We can most likely handle populating these manually while we are on the SHA network.

[kerrymcmahon]

What version are they missing? I can update them NOW at SHA. But I thought you meant KCI Prod.

[kerrymcmahon]

@ladejobi there should be no issue. I think he's just saying there are nulls. I just want to understand where the nulls are. I assume this is in all locations.

[KCI-Ablowers]

They are in the KCI_1 production version for what ever features were added during the first run of inspections and inventory updates. I can give you the IDs if need be.

[kerrymcmahon]

Ok so that's where I was confused, because you said you and maria could do them on the SHA network. KCI_1 Production is not SHA network.

The other thing is that I noticed in SHA production there are a lot of nulls also. Those are an easy edit.

I don't care who updates and where, but it needs to be done. It's an easy join by CONVEYANCE ID or by STRUCTURE ID.

Just let me know. there are two issues here, the new records, and existing records. And likely in all locations there are nulls.

[johnshiu]

FYI, this is not yet implemented in the ETL. I'll update this once it's in place, but it should be completed before any further field-to-source updates are made.

[talllguy]

@kerrymcmahon catching up here. Regarding "a lot of nulls," my goal is to give you and the SHA QC team less work, not more. 😉 When these versions start pouring in, easy edits could create quite a backlog. Are there any deficiencies in the way the field data is coming back with nulls? Perhaps we can iron those out while we're still rolling on the project.

[johnshiu]

This has been updated in the field-to-source script.

[talllguy]

@KCI-Ablowers next time you're in this office, test this one out and close out if completed.

[KCI-Ablowers]

I may have verified this in a previous production push. To be sure, the next time I have inventory updates that require entries to the related tables, I will make a note to check for this OR verify when I QAQC production.

[KCI-Ablowers]

Verified after most recent push to production in NPDPES Prod export