Re: desperate, need oracle help!

Well, in your defense, I think your company's system of security/checking/double-checking stinks. If a user (you) not privy to the inner workings of the database and its design, is allowed to make changes (or suggestions that result in changes) without a competent dba or modeler reviewing the consequences beforehand, then maybe you should submit that in your report as well. With that kind of system in place, you are guaranteed at some point to get a nice screw-up.

Three things:
- I'd ask your dba (or boss) to reinsert those columns and rows, and explain that you hadn't fully thought out the possibilities of your actions. Be honest and do this soon, the longer you wait the more damage that may result (I don't know your situation); - Recommend that more stringent policies be created that define what can be done by whom, and who is responsible for okaying _those_ actions; - and finally, I'd STRONGLY suggest that you have a little sit-down with your boss, dbas, and developers to get a good grasp on what all this data does, how it is all related, and why the database has been modeled that way it has.

Cheers and good luck,

Bricklen

IAC wrote:
>
> 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 Sun Apr 14 2002 - 16:46:06 CEST