April 08, 2005

sittin, drinkin, readin

It's Friday night, do you know where your beer is? Mine is about to come out of the fridge to be poured in a Headmaster glass (currently chilling) that I liberated from a pub in Sydney Australia a few years ago. I'm sitting at my computer (duh) listening to wndl's machine as it chug-chug-chugs through a laborious defragmentation. No wonder she was getting sluggish performance out of that old beast, it was horribly fragmented.

wndl herself is on the road, heading east to visit her mom. I'm home alone with the offspring for the weekend. It's like pre-loaded revenge for all the single parenting she'll have to do while I'm recovering from surgery next week.

My brain is a shriveled, husk-like memory of its previously moist and useful self. I used it far too much at work today. [pause here to get the beer, Black Butte Porter, of course]. Most of the day was spent on one project, which is a bit unusual. That one project wanted to be done already, so I was working extra hard. The project involves databases (Sybase and SQL Server) and the process of getting information from one to the other so that it could ultimately be served up on a website. I'd spent considerable time over the past couple of days altering stored procs and tables so that new data could be added to this information sharing process. The problem I faced this morning was that the new chunks of data I'd added weren't showing up on the far end.

The first thing I discovered was that I was updating the production table in one place and the test table in the other -- doh! Once I corrected that mistake, the extraction proc ran nicely, populating the production table as expected. Now I had to request that the DTS package responsible for the entire transfer be run. I couldn't just run it myself, even though I'm fully capable of doing so, I don't have the permissions on that database. At the Big Financial Company, production databases are off limits to mere development staff, even if we're the ones with the most intimate knowledge of the database objects we're altering. In order to change tables, procs etc, or to even run jobs on production databases, we are required to contact another contracted group who's in charge of the databases.

Usually that's fine and we get reasonable response in a timely fashion. Unfortunately, today, the response time was much slower and the guy I was requesting help from was second-guessing me. He ran the job, but it took 3 hours from the time I made my request. The job itself takes less than 20 minutes and I needed to see the results, evaluate them and decide what my next change had to be. Did I mention this project was a bit overdue? I realize the database support group was busy with other important projects, but it just points out the bottlenecks you can face when you split responsibilities this way.

Once I got the results of that job, I realized something was terribly wrong. The table I'd created on the source database, which was supposed to be copied to the destination, did not match the copy. I knew the problem was, the copy task in the DTS package was hinky, it wasn't copying the data as it should have. So I told my database group contact what was happening and that I needed him to open up that task and see what was happening. I could look at the DTS package, even inspect some of the properties, but I couldn't open that task. He decided to second guess me at that point and began looking at the extraction procedure, even querying one of the source tables. For crying out loud, that proc worked... just look at the source table! I explained the nature of the problem to him 3 times, each time more slowly than the last. Finally, he got it, opened the task and discovered the transformation mappings were all f*cked up. Fixing the problem took less than a minute, he saved the package and reran it. Bingo, data goes from end to end as expected.

Why didn't he just listen to what I was saying? I made a specific request and he ignored it in favor of blazing his own trail. Together we wasted about 30 minutes when 5 would have done the trick. that took both of us farther away from meeting our deadlines.

I'm sure this arrangement makes sense to some people, but in practice it's a pain in the ass and a real impediment to getting things done efficiently.

Well, my remaining brain cells are just about done in and I'm going to retire to my recliner to kill off the rest with this Porter.

Have a great weekend.

Posted by buggy at April 8, 2005 09:39 PM | TrackBack