Re: desperate, need oracle help!

Here's something else. Since you don't know the design or what various packages and procedures do, and since changes to the database are restricted to a select few, it's entirely possible that changes to the database are audited. In that case you'd get caught even if you figured out how to make the changes. So do what everyone else suggested and be honest.

You made the best decision with the knowledge you had at the time. New knowledge suggested the decision was wrong. Now the rows need to be re-inserted.

Van

"Jonathan Best" <j-best2NOSPAM_at_ERASETHISshaw.ca> wrote in message news:yZQu8.46279$ir6.1984717_at_news1.calgary.shaw.ca...
> This is what I read into it. You saw what you thought was a mistake in
the
> DB, so you did what you were supposed to do, and documented it and passed
it
> upward. To me, it sounds like your boss is the one who screwed up:
> 1. He didn't follow adequate change procedures (ie, check why something
is
> the way it is)
> 2. He took you at your word. (DB's should not be changed on one persons
> view. The change should be reviewed by at least one person. Can we say
DBA
> meeting?)
> 3. He didn't bother to learn the DB himself.
>
> Chill out and remember, your boss is the one on record approving the
change,
> even if you suggested it.
>
> HTH
> Jon
>
>
> "IAC" <"an"underscore"user"_at_"lycos"dot"com"> wrote in message
> news:ubit1oo0of8h7a_at_corp.supernews.com...
> > Okay, so here's my story. It's vague in some places, and I apologize,
but
> I
> > admit I am a little paranoid about our db admin coming across these
posts
> > and turning me in.
> >
> >
> >
> > My job is to run quick ad hoc queries on the information gathered by a
> > rather large R&D company. I then summarize what I find, and send it off
> to
> > the dept that requested it. No problems there. Along the way, however,
I
> > am supposed to identify quirks, flaws, abnormalities in the database
> and/or
> > the data itself. Should I find anything, I send a different type of
> report
> > to my boss stating what I've found and how it should be changed to make
my
> > life easier. This is where the problem is. Based on my suggestion,
> several
> > (15-20) rows have been removed, by my superior, from one table and
placed
> in
> > a newly created table, which, for my purposes makes much more sense.
> > However, I have come to the realization in the last couple of days that
> the
> > old way was set up that way for a reason. Come the end of April, there
> will
> > be an automated inspection of the data, which will now NOT include the
> rows
> > that have been relocated. These are the rows that need to be reinserted
> > into the original table before the end of the month.
> >
> >
> >
> > There are others at this corp. who are not exactly thrilled with my
status
> > (and salary) at a young age and who would jump at the chance to prove me
> > incompetent.
> >
> > the table with the missing rows kinda looks like this: (sorry if
something
> > doesn't make sense, I'm just trying to provide all the details I can.)
> > Primary Key - Integer
> > Short Code - text, 5 chars
> > Long Code - text 15 chars
> > Description - text 40-60 chars
> > Owner ID - Integer
> > Dept ID - Integer
> > Audit ID - Integer
> > Entry Date - Date
> > Expires - Date
> > Rating - number, 0.0 - 9.9
> > Process Codes - comma seperated list of Integers
> >
> > my boss has the ability to remove rows from this main table and also to
> > create other tables, but the privelege to add to or modify the main
table
> is
> > the hands of a very select few.
> >
> > if anybody has any more questions, keep them coming, please. Just the
> fact
> > that some are willing to take the time to ask gives me a bit of hope.
> >
> > IAC
> >
> >
>
>
Received on Wed Apr 17 2002 - 01:32:13 CEST