ISQL checks current directory before DBPATH?

Since upgrading to Informix SE V7.25 UC6R1 and ISQL V7.32 UC4, it seems that ISQL is checking for databases in the current working directory *before* looking in DBPATH. IBM support confirmed that this is the behavior and did not know any way to change it. When a user's home directory is NFS mounted, this causes error -25555 when attempting to select a database. I would prefer not to give SQL developers local directories, but to allow them to keep their SQL queries on their NFS mounted directories. The databases are of course on local drives as required. Is their any way to prohibit isql from looking in the current directory for databases before going to DBPATH? Thanks for your help! -Mark

Mark Conrad wrote: > Since upgrading to Informix SE V7.25 UC6R1 and ISQL V7.32 UC4, it > seems that ISQL is checking for databases in the current working > directory *before* looking in DBPATH. IBM support confirmed that this > is the behavior and did not know any way to change it. When a user's > home directory is NFS mounted, this causes error -25555 when > attempting to select a database. I would prefer not to give SQL > developers local directories, but to allow them to keep their SQL > queries on their NFS mounted directories. The databases are of course > on local drives as required. That's the way it has been since time immemorial - when it really mattered that databases were not on NFS file systems because the locking was downright abominable if it worked at all. > Is their any way to prohibit isql from looking in the current > directory for databases before going to DBPATH? Why would they be keeping a database in an their (NFS-mounted) current directory? Or is the trouble that SE looks at directories and decides whether the directory is usable before looking to see if there's a database in it? What about: echo 'cd /tmp; exec $INFORMIXDIR/bin/real.isql "$@"' \\ > $INFORMIXDIR/bin/mock.isql chmod 555 $INFORMIXDIR/bin/mock.isql mv $INFORMIXDIR/bin/isql $INFORMIXDIR/bin/real.isql ln -s mock.isql $INFORMIXDIR/bin/isql That way, the current directory is never NFS-mounted (unless someone has a very peculiar sense of sys-administorial humour) and there isn't any more problem. Now, if ISQL does not allow you to access a form or report stored on an NFS-mounted file system, then there's a different problem, and the code above won't help. But if it is strictly the database - you should be OK. Clearly, too, your choice of directory might be different from /tmp. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-2229 tiger2 2008-01-09 03:00:04 14CEAB5BD455C0B396ACF90E0D6F92E4896DE4D16E0FD843

----- Original Message ----- From: "Jonathan Leffler" <jleffler@earthlink.net> Newsgroups: comp.databases.informix To: <informix-list@iiug.org> Sent: Wednesday, January 09, 2008 12:01 AM Subject: Re: ISQL checks current directory before DBPATH? > Mark Conrad wrote: > > > >> Since upgrading to Informix SE V7.25 UC6R1 and ISQL V7.32 UC4, it >> seems that ISQL is checking for databases in the current working >> directory *before* looking in DBPATH. IBM support confirmed that this >> is the behavior and did not know any way to change it. When a user's >> home directory is NFS mounted, this causes error -25555 when >> attempting to select a database. I would prefer not to give SQL >> developers local directories, but to allow them to keep their SQL >> queries on their NFS mounted directories. The databases are of course >> on local drives as required. > > That's the way it has been since time immemorial - when it really > mattered that databases were not on NFS file systems because the locking > was downright abominable if it worked at all. > >> Is their any way to prohibit isql from looking in the current >> directory for databases before going to DBPATH? > > Why would they be keeping a database in an their (NFS-mounted) current > directory? Or is the trouble that SE looks at directories and decides > whether the directory is usable before looking to see if there's a > database in it? > > What about: > > echo 'cd /tmp; exec $INFORMIXDIR/bin/real.isql "$@"' \\ > > $INFORMIXDIR/bin/mock.isql > chmod 555 $INFORMIXDIR/bin/mock.isql > mv $INFORMIXDIR/bin/isql $INFORMIXDIR/bin/real.isql > ln -s mock.isql $INFORMIXDIR/bin/isql > > > That way, the current directory is never NFS-mounted (unless someone has > a very peculiar sense of sys-administorial humour) and there isn't any > more problem. > > Now, if ISQL does not allow you to access a form or report stored on an > NFS-mounted file system, then there's a different problem, and the code > above won't help. But if it is strictly the database - you should be OK. > > Clearly, too, your choice of directory might be different from /tmp. Will a reboot remove symbolic links from /tmp like it does regular files? Am I correct in assuming that the above might make "banging-out" of isql counterintuitive about where you'd bang-out to? As an editorial aside, I never have understood why SE automatically looked in the current directory first. I think most developers would be smart enough to prepend ".:" to $DBPATH if they wanted that behavior. Kind of a moot point now, I guess. Walt. > > > > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ > > publictimestamp.org/ptb/PTB-2229 tiger2 2008-01-09 03:00:04 > 14CEAB5BD455C0B396ACF90E0D6F92E4896DE4D16E0FD843 > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > >

Walt Hultgren wrote: > "Jonathan Leffler" wrote: >> Mark Conrad wrote: >>> Since upgrading to Informix SE V7.25 UC6R1 and ISQL V7.32 UC4, it >>> seems that ISQL is checking for databases in the current working >>> directory *before* looking in DBPATH. IBM support confirmed that this >>> is the behavior and did not know any way to change it. When a user's >>> home directory is NFS mounted, this causes error -25555 when >>> attempting to select a database. I would prefer not to give SQL >>> developers local directories, but to allow them to keep their SQL >>> queries on their NFS mounted directories. The databases are of course >>> on local drives as required. >> >> That's the way it has been since time immemorial - when it really >> mattered that databases were not on NFS file systems because the locking >> was downright abominable if it worked at all. >> >>> Is their any way to prohibit isql from looking in the current >>> directory for databases before going to DBPATH? >> >> Why would they be keeping a database in an their (NFS-mounted) current >> directory? Or is the trouble that SE looks at directories and decides >> whether the directory is usable before looking to see if there's a >> database in it? >> >> What about: >> >> echo 'cd /tmp; exec $INFORMIXDIR/bin/real.isql "$@"' \\ >> > $INFORMIXDIR/bin/mock.isql >> chmod 555 $INFORMIXDIR/bin/mock.isql >> mv $INFORMIXDIR/bin/isql $INFORMIXDIR/bin/real.isql >> ln -s mock.isql $INFORMIXDIR/bin/isql >> >> >> That way, the current directory is never NFS-mounted (unless someone has >> a very peculiar sense of sys-administorial humour) and there isn't any >> more problem. >> >> Now, if ISQL does not allow you to access a form or report stored on an >> NFS-mounted file system, then there's a different problem, and the code >> above won't help. But if it is strictly the database - you should be OK. >> >> Clearly, too, your choice of directory might be different from /tmp. > > Will a reboot remove symbolic links from /tmp like it does regular > files? Yes, but I didn't create any symlinks in /tmp. The name $INFORMIXDIR/bin/isql contains a link to mock.isql, which is another file in $INFORMIXDIR/bin. > Am I correct in assuming that the above might make "banging-out" > of isql counterintuitive about where you'd bang-out to? Well, yes - but it would also make it consistent. You'd always be in /tmp (or wherever you decide to change directory to). > As an editorial aside, I never have understood why SE automatically > looked in the current directory first. I think most developers would be > smart enough to prepend ".:" to $DBPATH if they wanted that behavior. > Kind of a moot point now, I guess. Probably because the pre-ISQL product, Informix, did it that way, and with better reason; the database dictionary was stored in a .dbd file in the same directory, generally, as the .dat and .idx (and often .lok) files, not to mention the forms and reports and ... -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ publictimestamp.org/ptb/PTB-2229 whirlpool 2008-01-09 03:00:04 D0CA3305E9DDDBF4FD377C36D20BFCCCBF750B6EEC7ECB3769618B1A0F602893A69FCE 03744D83EFA12D941FB34651100D09D88C4FBB5193AF58D80B522CC8A