Re: A better SQL*Plus -- what features should it have?

In article <aqglm4$9usfg$1_at_ID-86071.news.dfncis.de>, rogel_at_web.de says...
> this gains me:
>
> 1. I don't have to go to each client machine and look if their
> tnsnames.ora is set up correctly
>
> 2. what I want to type in is
> a. HOST
> b. SID
> (it is not so hard to write a routine that builds up all the rest of
> it, if U wish, I can send U one, it even is able to count parens
> right !)
>
> 3. I then *KNOW* on which Host and which SID I am
> (without looking into tnsnames.ora !!)
>
> MaRo
>
> By the way,
>
> 1. Thin JDBC doesn't use tnsnames.ora either
> (well it does not use SQL*Net Client, so this is clear)
> Instead, it is easy to build the JDBC-Connect-String from the
> two parameters HOST and SID.
>
> 2. Everytime I learn a new programming language, one of the first
> programs for me to write is an SQL-Client
> (The last one was Delphi, the one before Java, ...)
> I prefer to work with my own Clients instead of SQL*Plus; of course
> the Delphi-Client is a GUI.
> I don't need a prompt showing me on which database I am
> (resp. on which alias in tnsnames.ora), since on the top of my GUI
> I have
> a. DB-Vendor (might be, in this case Oracle or MS-SQL or Interbase)
> b. Host (where is Server running)
> c. Database (in case Oracle, this is what U call SID, well it is now
> called SERVICE_NAME by Oracle)
> d. Username

And how do you handle cool stuff like multiple address lists, load balancing, failover, source routes, service types, connect data, and some other stuff I can't think of right now?

• Tom