Re: Edit records with an Oracle client

From: jgar the jorrible <>
Date: Wed, 1 Apr 2009 10:46:02 -0700 (PDT)
Message-ID: <>

On Mar 30, 7:56 pm, Palooka <> wrote:
> Michael Austin wrote:
> > Palooka wrote:
> >> francan wrote:
> >>> I just loaded the 10g client EM on my Windows workstation to connect
> >>> to our 10g database.
> >>> Everything works great except I dont see any place where I can edit
> >>> records. I have to use SQL Plus to edit records but was hoping to use
> >>> a GUI like I had with 9i client OEM.
> >>> Before we had 10g, I used to have the 9i OEM and it let me edit
> >>> records in 9i OEM where I could add, delete and update records with a
> >>> user friendly interface.
> >>> Please advise where or how I can edit records in 10g EM or Oracle
> >>> client?
> >> You want to edit in a spreadsheet like grid in 10g? You can use
> >> iSQL*Plus, SQL Developer, or any number of tools.
> >> Palooka
> > I find that trying to edit live data with a "spreadsheet" tool to be a
> > very dangerous thing - especially if you really do not understand the
> > data...
> True enough, but no more dangerous than using SQL*Plus. After all, it's
> the database permissions which determine what is what; not the choice of
> client tool.
> Palooka

I see both sides of this on a daily basis, the enterprise software has a specific tool for doing this, including a way for us techies to write programs limiting what users can do. Sometimes it's just a lifesaver. The potential for worse than "truncate table" exists - at least with a truncate, you can get all the data back through recovery. Trying to fix an untraceable data change after an indeterminate time, yikes. Quickly fixing 3 rows in 5 tables messed up from a vendor bug without having to backdoor with sql - priceless.

That said, note that the view data function in EM allows showing the sql used in for the query. This can be easily cut and pasted into the ordinary edit window of SQL*Plus. For me this is not much different than how I often work in sqlplus - I make sure the data set is what I want with a query, then I copy and convert it to an update with a rollback in a script, then when I feel comfortable I pull out the rollback. Then I do it in production. Then when I'm done I put a notfication prompt and an exit at the beginning of the script (or move towards production quality if appropriate). This also makes it easy to keep a log file of what data was changed. That has saved my ass numerous times, being able to go back and say "hey, this is what so- -so told me to do, this is what was done, what's the problem?" A lot of this is data updates from people we don't want directly updating the system, let them do whatever the hell they want with Excel then scrub iteratively. Way too many squishy business rules to program - the rules that are already programmed are crazy-making.


-- is bogus.
Received on Wed Apr 01 2009 - 12:46:02 CDT

Original text of this message