dbaccess startup harder for us now
After their database moved to a remote AIX host, users had to wade through dbaccess's Connection menus (server, username, password) instead of just picking a database, which was tedious for quick ad-hoc queries. Suggestions included IIUG's SQLCMD (with a password file), and simply running 'dbaccess dbname@server'. The poster found the practical answer himself: a script file beginning with CONNECT TO 'database' USER 'username' USING 'password'; followed by the SQL, run as 'dbaccess - filename'. He noted no equivalent exists for the full-screen menu mode, where error 956 ("not trusted by the server") still forces the manual connect sequence.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Our organization's security specialists
are tying us in knots. As a result, starting
up dbaccess got harder when the database was
moved to a different AIX host. I'm wondering if
there are simplifications I could call to the
attention of our database administrator --
or implement on my own via a script.
Before, we invoked dbaccess this way:
--execute "dbaccess"
--choose "Query-language" from menu DBACCESS:
--choose database from short list
--choose action from menu SQL: [e.g. "New"]
Now it's like this:
--execute "dbaccess"
--choose "Connection" from menu DBACCESS:
--choose "Connect" from menu CONNECTION:
--choose database server from short list
--enter username
--enter password
--choose database from short list
--choose Exit from menu CONNECTION:
--choose Query-language from menu DBACCESS:
--choose action from menu SQL: [e.g. "New"]
For somebody who needs to do a one-shot
query right NOW this is a hassle.
As the team's Perl specialist, I can write
scripts for one-shot queries that are just
pasted from a templates. This is usually
enough for me, but my co-workers are used
to dbaccess and I'd like to give them a
quick way to get in and out. I'm thinking
of trying an Expect script, but I'll have
to learn Expect, so I wanted to check here
first to see if I'm reinventing the wheel.
--
Charles Packer
mailboxATcpacker.org
mailbox@cpacker.org wrote:
> Our organization's security specialists
> are tying us in knots. As a result, starting
> up dbaccess got harder when the database was
> moved to a different AIX host. I'm wondering if
> there are simplifications I could call to the
> attention of our database administrator --
> or implement on my own via a script.
>
> Before, we invoked dbaccess this way:
> --execute "dbaccess"
> --choose "Query-language" from menu DBACCESS:
> --choose database from short list
> --choose action from menu SQL: [e.g. "New"]
>
> Now it's like this:
> --execute "dbaccess"
> --choose "Connection" from menu DBACCESS:
> --choose "Connect" from menu CONNECTION:
> --choose database server from short list
> --enter username
> --enter password
> --choose database from short list
> --choose Exit from menu CONNECTION:
> --choose Query-language from menu DBACCESS:
> --choose action from menu SQL: [e.g. "New"]
>
> For somebody who needs to do a one-shot
> query right NOW this is a hassle.
> As the team's Perl specialist, I can write
> scripts for one-shot queries that are just
> pasted from a templates. This is usually
> enough for me, but my co-workers are used
> to dbaccess and I'd like to give them a
> quick way to get in and out. I'm thinking
> of trying an Expect script, but I'll have
> to learn Expect, so I wanted to check here
> first to see if I'm reinventing the wheel.
Well, one possibility might be SQLCMD:
sqlcmd -u username -d dbase@server -e 'sql statement'
or
sqlcmd -u username -d dbase@server
for interactive work (including a history mechanism with editing of
previous statements).
There are a number of other options, including specifying a CONNECT
statement in the script being executed (with no messing around having to
type the password on request). You can even pass the password on the
command line - highly unrecommended, but possible.
You mentioned passwords - there's a mechanism in SQLCMD that I adopted
from INFOTABLE. You can create a file which lists database or
database@server plus username and password. SQLCMD will read the
password from that file if you connect to the database - and there are
documented rules for which username it will use if there are multiple
entires for a single database server.
SQLCMD is available from the IIUG.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
On 25 Jan, 17:16, mail...@cpacker.org wrote:
> Our organization's security specialists
> are tying us in knots. As a result, starting
> up dbaccess got harder when the database was
> moved to a different AIX host. I'm wondering if
> there are simplifications I could call to the
> attention of our database administrator --
> or implement on my own via a script.
>
> Before, we invoked dbaccess this way:
> --execute "dbaccess"
> --choose "Query-language" from menu DBACCESS:
> --choose database from short list
> --choose action from menu SQL: [e.g. "New"]
>
> Now it's like this:
> --execute "dbaccess"
> --choose "Connection" from menu DBACCESS:
> --choose "Connect" from menu CONNECTION:
> --choose database server from short list
> --enter username
> --enter password
> --choose database from short list
> --choose Exit from menu CONNECTION:
> --choose Query-language from menu DBACCESS:
> --choose action from menu SQL: [e.g. "New"]
>
> For somebody who needs to do a one-shot
> query right NOW this is a hassle.
> As the team's Perl specialist, I can write
> scripts for one-shot queries that are just
> pasted from a templates. This is usually
> enough for me, but my co-workers are used
> to dbaccess and I'd like to give them a
> quick way to get in and out. I'm thinking
> of trying an Expect script, but I'll have
> to learn Expect, so I wanted to check here
> first to see if I'm reinventing the wheel.
>
> --
> Charles Packer
> mailboxATcpacker.org
Not sure if I'm misunderstanding your problem, but what's wrong with
simply issuing the command
dbaccess <databasename>@<connectionname>
(e.g. dbaccess stores@testshm)
on the command line?
>From: malc_p@btinternet.com
>
>On 25 Jan, 17:16, mail...@cpacker.org wrote:
> > Our organization's security specialists
> > are tying us in knots. As a result, starting
> > up dbaccess got harder when the database was
> > moved to a different AIX host. I'm wondering if
> > there are simplifications I could call to the
> > attention of our database administrator --
> > or implement on my own via a script.
> >
> > Before, we invoked dbaccess this way:
> > --execute "dbaccess"
> > --choose "Query-language" from menu DBACCESS:
> > --choose database from short list
> > --choose action from menu SQL: [e.g. "New"]
> >
> > Now it's like this:
> > --execute "dbaccess"
> > --choose "Connection" from menu DBACCESS:
> > --choose "Connect" from menu CONNECTION:
> > --choose database server from short list
> > --enter username
> > --enter password
> > --choose database from short list
> > --choose Exit from menu CONNECTION:
> > --choose Query-language from menu DBACCESS:
> > --choose action from menu SQL: [e.g. "New"]
> >
This is normal.
You're no longer connecting to a local instance so the machine has to verify
that you are who you say you are.
Have you tried running any form of single sign on like LDAP?
And I think you can pass in variables on the command line of DBACCESS to
provide some of that information too...
> > For somebody who needs to do a one-shot
> > query right NOW this is a hassle.
> > As the team's Perl specialist, I can write
> > scripts for one-shot queries that are just
> > pasted from a templates. This is usually
> > enough for me, but my co-workers are used
> > to dbaccess and I'd like to give them a
> > quick way to get in and out. I'm thinking
> > of trying an Expect script, but I'll have
> > to learn Expect, so I wanted to check here
> > first to see if I'm reinventing the wheel.
> >
> > --
> > Charles Packer
> > mailboxATcpacker.org
>
>Not sure if I'm misunderstanding your problem, but what's wrong with
>simply issuing the command
>dbaccess <databasename>@<connectionname>
>(e.g. dbaccess stores@testshm)
>on the command line?
>
>_______________________________________________
>Informix-list mailing list
>Informix-list@iiug.org
>http://www.iiug.org/mailman/listinfo/informix-list
_________________________________________________________________
Turn searches into helpful donations. Make your search count.
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG
On Jan 26, 8:49 am, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
> You're no longer connecting to a local instance so the machine has to verify
> that you are who you say you are.
>
> Have you tried running any form of single sign on like LDAP?
>
> And I think you can pass in variables on the command line of DBACCESS to
> provide some of that information too...
Apparently not for the full-screen
version. But it turns out I can run dbaccess
with a command file in the non-menu mode, even
when the database is non-local. (Therefore
there's no need for sqlcmd, incidentally.)
What I discovered after a little RTFM and
experimentation is that a file containing
something like this:
CONNECT TO 'database' USER 'username' USING 'password';
SELECT [whatever];
...works fine when executed like this:
dbaccess - filename
However, it looks like there's no way
to invoke the full-screen version
with a command file. Even doing
dbaccess database
results in dbaccess starting at the top
menu and displaying error 956 at the
bottom of the screen ("...not trusted by
the server") and being forced to wade
through all the menu choices I indicated
in the original posting. Unless...there's
some menu item that would accept
that "CONNECT TO" statement that I used
in the command file for the noninteractive
version. I haven't found it yet.
--
Charles Packer
mailboxATcpacker.org
There is such a CONNECT menu item.
dbaccess (no options)
Connection
j.
-----Original Message-----
From: informix-list-bounces@iiug.org
[mailto:informix-list-bounces@iiug.org]On Behalf Of mailbox@cpacker.org
Sent: Friday, January 26, 2007 2:14 PM
To: informix-list@iiug.org
Subject: Re: dbaccess startup harder for us now
On Jan 26, 8:49 am, "Ian Michael Gumby" <im_gu...@hotmail.com> wrote:
> You're no longer connecting to a local instance so the machine has to
verify
> that you are who you say you are.
>
> Have you tried running any form of single sign on like LDAP?
>
> And I think you can pass in variables on the command line of DBACCESS to
> provide some of that information too...
Apparently not for the full-screen
version. But it turns out I can run dbaccess
with a command file in the non-menu mode, even
when the database is non-local. (Therefore
there's no need for sqlcmd, incidentally.)
What I discovered after a little RTFM and
experimentation is that a file containing
something like this:
CONNECT TO 'database' USER 'username' USING 'password';
SELECT [whatever];
...works fine when executed like this:
dbaccess - filename
However, it looks like there's no way
to invoke the full-screen version
with a command file. Even doing
dbaccess database
results in dbaccess starting at the top
menu and displaying error 956 at the
bottom of the screen ("...not trusted by
the server") and being forced to wade
through all the menu choices I indicated
in the original posting. Unless...there's
some menu item that would accept
that "CONNECT TO" statement that I used
in the command file for the noninteractive
version. I haven't found it yet.
--
Charles Packer
mailboxATcpacker.org
_______________________________________________
Informix-list mailing list
Informix-list@iiug.org
http://www.iiug.org/mailman/listinfo/informix-list