I work for a utility company and each year (as ad valorem tax time rolls around) it's my job to report property counts by tax jurisdiction on 17-million items of property. Of course, before running the process, I have to validate the data my process uses. And naturally I always find data errors that need to be corrected. The problem is that the database my program uses is "Production", meaning only DBAs (database analysts) are authorized to make corrections to those tables. I (not being numbered among the anointed DBA priesthood) merely submit requests to have the data corrected. Last year I was very pleased to discover that only one record of one table related to one tax jurisdiction needed to be corrected, but ... well, here's the after-action report I sent to the manager who's responsible for that tax data.
Last year in hopes of expediting the correction of three "boundary segment" tables, I sent SQL scripts directly to the DBAs. Understandably, they were reluctant to make wholesale changes to Production tables based on my email request, so they asked me to route my requests through you. Thank you for being responsive to my flood of requests, but since you have better things to do than act as the postman for my SQL scripts, you asked me to route these requests through the Help Desk. I apologized for flooding your inbox and vowed to follow proper protocol in the future. This year I was feeling pretty proud of myself for remembering to route my request to the Help Desk. But alas, it seems I have again erred.
Yesterday I sent the Help Desk a request to have the DBAs run one SQL update command. In hopes of convincing the DBAs that I really do know what I'm doing and to allay any fears they might have about making changes to Production tables, I enclosed a very detailed explanation of why I was requesting this (including a JPEG image of the affected tax jurisdiction and evidentiary SQL select commands, pointing directly to the problem).
Upon receiving a courtesy copy of my Help Desk request, John G [the maintainer of jurisdictional boundaries] tried to help out by running the "link create" command of the boundary maintenance software. (I take full blame there. I should not have copied John on that note - my mistake.) But that being the case, John's change had the effect of adding a new record to the table (thus accomplishing half of what the update command was intended to do - inserting a correct record - but leaving the erroneous record unchanged). So I was obliged to modify my request - changing my "update" command to a "delete".
I crafted a quick amending note to the Help Desk, asking them to have the DBAs run the enclosed "delete" command, not the "update" of my previous note. In response to my modified request, your Help Desk forwarded my note to my boss, asking him to "follow up" on my request. (I need to thank the Help Desk for copying me on their note to my boss since that meant I didn't have to wait for him to delegate to me the job of following up on my request.) I called the Help Desk and spoke to Lana M, asking her to send my request to the DBAs, not to my boss.
Lana later sent me a note, apologizing for misrouting my request and reporting that all was well - my requested SQL command had been processed. I queried the table and discovered that just as Lana had reported, the "update" (not my amending "delete" request) had in fact been processed - thus creating two identical records. This was now a new problem. I replied to Lana's note, asking her to have the DBAs contact me and propose a fix.
It's not that I did't think I could craft the two SQL commands that would fix this problem. But I wasn't at all certain I could get the Help Desk to correctly communicate my suggestions to the DBAs. (I accept blame for the Help Desk's having the DBAs execute the wrong SQL command. I think it was the JPEG. My first note with the pretty colored picture in it was clearly the more alluring and had the marks of a well-thought-out tome. My amending request was rather slap-dash and didn't have near the eye-catching sparkle of the first note. It's not at all surprising that the Help Desk opted for the pretty colored picture.)
I might have been tempted to ignore this problem rather than once again call on the Help Desk to mediate, but at this point we'd passed the point of no return. My ad valorem tax program detects such duplications and aborts the process when it finds what is clearly erroneous boundary data. Thus, what was once a minor problem (which would have caused us to report no property within the Rule ISD) had been escalated (due to the Help Desk's "help") to a serious problem that prevented me from running the ad valorem tax process at all.
So, as soon as I realized what the DBAs had done, I emailed Lana back, asking her to have the DBAs propose a fix. (My reasoning was that this will probably flush a DBA out of the bushes and I might be able to speak to someone who can actually help.) Lana replied with another apologetic email, and copied the DBAs, instructing them to contact me.
I just spoke to one of the DBAs, Shane S. He informed me that they had undone all the changes, thus leaving the records as they were after John G added the new record. I said, "OK, in that case all we need to do is run that 'delete' command". Shane replied, "What 'delete'?" It seems that Lana had neglected to forward to the DBAs that amending note, the one which she'd routed to my boss. I forwarded them that "delete" command. Shane executed it and did a commit. Thus, the problem has been fixed.
Now, please don't be too hard on Lana. I think she just got caught in the middle on this request. She did her best to help. Making her feel bad about this incident will not make her better at her job. But at this point I'm left wondering: Which is the best approach? Would it be better to have my scripts rejected by the DBAs and kicked back for your approval (i.e., the "pester-and-grovel" approach) or to have my scripts repeatedly misunderstood and misrouted by the Help Desk until the cyclic corrections, recriminations and apologies dampen out (i.e., the "mishandle-and-fix" method)?
I tend to favor the "pester-and-grovel" option since it doesn't require me to repeatedly try to get information through the Help Desk filter. Besides, the results speak for themselves - last year I was able to insert hundreds of records just as fast as I could generate the scripts; whereas this year I was stymied for a whole day in my attempts to correct one character of one column of one record of one table.
The irony of all this is that I (as the only person who has a vested interest in making sure the political boundary tables are correct) am being thwarted in my efforts to plug the holes in the data which well-written boundary maintenance software would have prevented in the first place.
Please advise on how I should route these requests in the future.
The manager replied: "Just send your requests to me."
As I said, we render ad valorem taxes once a year. And soon it'll again be time to clean up the tax jurisdiction data in preparation for advalorem tax processing. Wish me luck.
