Print Story A Day in the Life -- You CAN be too careful
Working life
By ReallyEvilCanine (Tue Dec 21, 2010 at 09:09:09 AM EST) (all tags)
Sanjay wants to perform a simple operation: changing the department identity code on the database. It took him two full, single-spaced pages to ask whether it can be done. I needed 47 words to confirm this and accurately explain how to do it, including a warning.

But I'm getting ahead of myself...
x-posted from da brog



Currently in $Telco app, department identity is getting generated with A5-. We wanted identity to start with 71- instead of A5-.

1. Can you please let us know the possible solution for this?
Currently our database is going to migrate from Oracle 9i to Oracle 10g. So the approach you suggest will it be applicable for both oracle clients i.e. Oracle 9i or Oracle 10g.

2. Also we wanted to know if we start generating the department identity with 71- then do you foresee any issues while accessing orders / faults / asset data which is present in the current application.

Do let us know if you require more information.

Thanks & Regards,


"Sure thing. It's simple. To change the department identity you'll need to access the database directly and modify the DEPT_INDENT field of the YBA_IDENTIFICATION table with the value you want. Afterwards you must restart the full system. WARNING: do not change any other value on this table!

"Love, REC"

And that should've been the end of it. It always should be and it never is. Ever. I'm too busy today to piss and moan about subcontinental torture of the Muvver Tongue.

Hi_ Thanks for the update.
we got following queries on the approach suggested by you.
a) The approach of changing DEPT_IDENT field of the YBA_IDENTIFICATION table_ will it work in both clients i.e. Oracle 9 and Oracleus know the possible solution for this?
Currently our database is going to migrate from Oracle 9i to Oracle 10g. So the approach you suggest will it be applicable for both oracle clients i.e. Oracle 9i or Oracle 10g.

2. Also we wanted to know if we start generating the department identity with 71- then do you foresee any issues while accessing orders / faults / asset data which is present in the current application.

Do let us know if you require more information.

Thanks & Regards,


"Sure thing. It's simple. To change the department identity you'll need to access the database directly and modify the DEPT_INDENT field of the YBA_IDENTIFICATION table with the value you want. Afterwards you must restart the full system. WARNING: do not change any other value on this table!

"Love, REC"

And that should've been the end of it. It always should be and it never is. Ever. I'm too busy today to piss and moan about subcontinental torture of the Muvver Tongue.

Hi_ Thanks for the update.
we got following queries on the approach suggested by you.
a) The approach of changing DEPT_IDENT field of the YBA_IDENTIFICATION table_ will it work in both clients i.e. Oracle 9 and Oracle 10_
b) If we do above change then will it have any impact on the inlife date i.e. ordertabase is going to migrate from Oracle 9i to Oracle 10g. So the approach you suggest will it be applicable for both oracle clients i.e. Oracle 9i or Oracle 10g.

2. Also we wanted to know if we start generating the department identity with 71- then do you foresee any issues while accessing orders / faults / asset data which is present in the current application.

Do let us know if you require more information.

Thanks & Regards,


"Sure thing. It's simple. To change the department identity you'll need to access the database directly and modify the DEPT_INDENT field of the YBA_IDENTIFICATION table with the value you want. Afterwards you must restart the full system. WARNING: do not change any other value on this table!

"Love, REC"

And that should've been the end of it. It always should be and it never is. Ever. I'm too busy today to piss and moan about subcontinental torture of the Muvver Tongue.

Hi_ Thanks for the update.
we got following queries on the approach suggested by you.
a) The approach of changing DEPT_IDENT field of the YBA_IDENTIFICATION table_ will it work in both clients i.e. Oracle 9 and Oracle 10_
b) If we do above change then will it have any impact on the inlife date i.e. orders_ faults and assets data present on production system.
c) After above  DEPT_IDENT  field change_ do we have to do a complete enterprise restart or can this change be done online without restart the server.

I have attached the extract of YBA_IDENTIFICATION table from production environment for your reference. Do let me know if you need more information. Thanks and Regards

Da fuck? Since when does a database version affect the contents of a fucking 8-character field? I don't care what's in the table. There's one field to change and it's the only field you can touch on this table without blowing up your system.

will it work in both clients i.e. Oracle 9i & Oracle 10g?
It's not something you repeatedly change. It's changed once by the administrator.

b) If we do above change then will it have any impact on the inlife date
This is an internal reference number which is combined with SEQUENCEs to build serial and reference numbers. Noi historical data can be affected.

c) do we have to do a complete enterprise bounce
Yes.

And that should have finally been the end of it. Except that it never is.
Pleas having the manager calling to confirm because this does not seem fully correct. and we need to know before we initiate the effect.

Go fuck yourself. On the plus side, this nitwit technically asked to escalate to a manager so it's now Meathead's problem.

< Mr. Plow | Obviously, you're not a golfer. >
A Day in the Life -- You CAN be too careful | 13 comments (13 topical, 0 hidden) | Trackback
couldn't your last email have been the first? by infinitera (4.00 / 1) #1 Tue Dec 21, 2010 at 11:17:52 AM EST
A few extra words doesn't hurt, unless you're just saving them for the day in the life entries.

[…] a professional layabout. Which I aspire to be, but am not yet. — CheeseburgerBrown

This is a distillation by ReallyEvilCanine (4.00 / 1) #3 Tue Dec 21, 2010 at 12:10:58 PM EST
There were, I believe, 8 rounds of E-Mail between us in which I continually answered every stupid question. I have refrained from quoting everything because it both hurts too much to read over again and because you would find it boring and unbelievable. One day I may just cut & paste an HTML-formatted MS LookOut mail chain export and be done with it.

the internet: amplifier of stupidity -- discordia

[ Parent ]
ah by infinitera (4.00 / 2) #4 Tue Dec 21, 2010 at 12:45:28 PM EST
I've had a slight variation on this sort of exchange with Chinese and Japanese customers.

"We know the principles of software design, your answers about product behavior do not fit this, you must be wrong."

...

[…] a professional layabout. Which I aspire to be, but am not yet. — CheeseburgerBrown

[ Parent ]
This reminds me of when by ammoniacal (2.00 / 0) #2 Tue Dec 21, 2010 at 11:20:06 AM EST
our subcontinental sister pro coy was allowed to contribute to op orders in the bn s-3 shop. Much gnashing of the teeth commenced.

"To this day that was the most bullshit caesar salad I have every experienced..." - triggerfinger

Numbers by duxup (2.00 / 0) #5 Tue Dec 21, 2010 at 02:08:17 PM EST
Today a coworker was working a case where an OEM's customer saw two errors.   They occurred four days apart.  They have never seen these errors before.

The customer then called us and wanted absolute assurance that this wouldn't happen four days from now.   Now I never make such assurances and my coworker also is smart enough to do that except to say we don't know enough of the issue to know if it will or won't occur again.  Then they demanded some evidence that it wouldn't happen ever four days... and kept freaking out about it.  We never could get them to explain why they thought it would occur every four days.

____
it's like grandparents and computers by infinitera (4.00 / 2) #6 Tue Dec 21, 2010 at 03:16:31 PM EST
They make up theories to explain what it's "thinking". Theories with no relation to anything.

[…] a professional layabout. Which I aspire to be, but am not yet. — CheeseburgerBrown

[ Parent ]
You didn't seem to answer his fucking question. by dmg (2.00 / 0) #7 Tue Dec 21, 2010 at 07:29:31 PM EST
Which, you should recognize is a clear attempt at CYA. So, the correct response would be, to use e-prime (which it appears to me is the way forward for all business communication in this age of blame culture).

"I can see no reason why this wouldn't work with Oracle 9i Or 10g, of course it would be prudent to test this on your development/uat server to be completely sure".

Thus, neatly answering the question, and putting the responsibility back on them.

Are you NEW?


--
dmg - HuSi's most dimwitted overprivileged user.
There's CYA.. by infinitera (2.00 / 0) #8 Tue Dec 21, 2010 at 09:21:54 PM EST
And then there's "Can you assure me that my computer will not explode if I change this configuration?"

I think this is more the latter. Attemping to address the original question requires accepting false premises.

[…] a professional layabout. Which I aspire to be, but am not yet. — CheeseburgerBrown

[ Parent ]
No false premises there... by dmg (2.00 / 0) #13 Wed Dec 22, 2010 at 06:34:12 PM EST
Computers have been known to explode or at least catch fire under certain circumstances.

But even if there are false premises, if you answer the question carefully enough, using e-prime, and recommending that they test any proposed solution (managers hate this, because 9 times out of 10 dev/uat doesn't exist or doesn't match production), they have no comeback. You can then just keep forwarding your original email response. It can become very entertaining when you get good at this, watching them twist and turn as they try to find ways of re-phrasing their question to try and get a response from you that will render you responsible for their imminent failure.

Often, they already know the answer to the question too, they're just trying to get a scapegoat lined up in advance... 
--
dmg - HuSi's most dimwitted overprivileged user.
[ Parent ]
Oh dear by Herring (4.00 / 2) #9 Tue Dec 21, 2010 at 10:09:09 PM EST
If all the department codes are to start with "71" then there is clear data duplication - which is an indication of insufficient normalisation. I recommend always assuming 7th normal form where items in a text column are not allowed to rhyme.

christ, we're all old now - StackyMcRacky
It's been a while by gazbo (4.00 / 2) #10 Wed Dec 22, 2010 at 04:39:41 AM EST
Since I felt the need to sig someone.

I recommend always assuming 7th normal form where items in a text column are not allowed to rhyme.

[ Parent ]
Sorry by Herring (4.00 / 1) #11 Wed Dec 22, 2010 at 08:23:33 AM EST
Stolen from Verity Stob.

I write very little of my own material.

christ, we're all old now - StackyMcRacky

[ Parent ]
Swine! by gazbo (2.00 / 0) #12 Wed Dec 22, 2010 at 08:29:38 AM EST
Consider your credit rescinded!

I recommend always assuming 7th normal form where items in a text column are not allowed to rhyme.

[ Parent ]
A Day in the Life -- You CAN be too careful | 13 comments (13 topical, 0 hidden) | Trackback