Re: desperate, need oracle help!

it's rather easy to reinsert the rows ... if that was all that was done. however, the problem isn't really the data alteration ... it is obvious that you inherited a database without adequate documentation or documented but unknown to you. your understanding of the consequences of removing the data, especially before a critical date, is an accomplishment. but from your description of your environment, the problem is feeling that you have to be correct and can't make mistakes.

hopefully, you've learned two important lessons here: 1) don't jump too conclusion too quickly 2) don't make the original mistake worse.

i'd go directly back to your boss with the information you now have. instead of declaring a need to reverse the removal, approach it as: "here's new information ... what do you think ... do you agree". your boss made the actual changes and therefore he/she is responsible for the correction. you might offer to document this new information for future reference.

"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 Tue Apr 16 2002 - 07:23:02 CEST