Friday, April 07, 2006

Who needs permission?

You know, we really don't write these basic scripts for shits and giggles. They actually do stuff. Why do people think otherwise?

No, we're the company that actually makes the base software. We get the money if you use the software. It's in our best interest to write as little as possible and do so as cleanly as possible. Now, no app this big and variable is "clean", but it's relatively cruft-free and it works pretty well. After various security incidents we also found it to be in our best interest to lock as many people as possible out of system areas and access points and let only our internal components do the actual reading and writing.

Since every insert, delete, drop, and change to the database is handled by the sytem's own admin user account, it would stand to reason that this acount would need full access to the database. My techno-tard sister understands this (as long as I put it into restaurant terms, thusly):
"The restaurant is being more careful with the booze. The customers can't pour their own drinks; they have to ask the waiters. The waiters have to go ask the bartender for the order. When the bartender runs out of some bottle -- say, Hendrick's Gin -- he has to go to the manager for a fresh bottle. The manager then has to go to the basement to get the bottle from the liquor cage. All clear?"

"Sure. So what's the problem?"

"The landlord won't give the manager the basement key."

So I think it's understandable that I was more or less gobsmacked by this beauty of a Service Ticket:
"The database administrator refuses to execute the InitialUserSetup.sql and he wants to give to the two Admin users the permissions that he considers pertiment - I want to know the implications of this practice in the rest of the aplication."
[emphasis mine]
The my-head-shaped-dent in front of my keyboard received my forehead in much the same way as the Utah desert received the Genesis probe.

He then continued explaining that he had another problem, namely stuff like:
[DataDirect][ODBC Oracle driver]String data, right truncated. Error in parameter 18.
Error inserting row 147433 into table $TABLE
Thousands of lines like it following Every. Single. Operation.

So, in summary, the Database Administrator doesn't want to grant the system permission to access its own database, and the Application Dude doesn't understand why writes to the database are failing.

I need a Root Cause 34 for this SR. The pair of 'em.


Anonymous Anonymous pulled out a crayon and scribbled:

Yo my man,

if I hadn't read a few posts before I wouldn't have understood root cause 34 - that dude certainly deserves it :-)

Hang in there and wait for $BigCorp
to change to $HugeCorp and see what
you can get there.

An insider who knows what he's talking about

15 May, 2006 19:36  
Blogger ReallyEvilCanine pulled out a crayon and scribbled:

Heh. Great to hear from one of my Big Red Brethren. Feel free to confirm that I'm not making a single word of this shit up.

To understand "17" you have to remember how root causes used to be listed. I still remember throwing out so many 3s, 6s and 13s it would make your head spin. I did campaign for a 17-like root cause but despite my colleagues' support, the namby-pamby "Customer Lack of Understanding" was implemented instead.

I have no misconceptions about the move to $HugeCorp. What really sucks is that I won't even have a proper fucking cubicle anymore. I may have to buy a metric buttload of Lego and make my own walls. With $HugeCorp's logo in there, natch.

20 May, 2006 16:03  

Post a Comment

<< Home

In compliance with $MegaCorp's general policies as well as my desire to
continue living under a roof and not the sky or a bus shelter, I add this:

The views expressed on this blog are my own and
do not necessarily reflect the views of $MegaCorp, even if every
single one of my cow-orkers who has discovered this blog agrees with me
and would also like to see the implementation of Root Cause: 17-Fuckwit.