Re: ISQL checks current directory before DBPATH?

On Jan 9, 12:01 am, Jonathan Leffler <jleff...@earthlink.net> 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. I'm not so suire about that. My ancient 7.20 installation on Solaris (8+ year old installation) either doesn't look in the current working directory first, or doesn't care that it's NFS mounted. It finds the databases on the locally mounted DBPATH, and the forms/reports/queries in the NFS mounted current working directory. > > > 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? The trouble is that ISQL is looking in the current working directory before DBPATH. I agree, nobody should be accessing a database over NFS. > > 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. ISQL does allow you to access forms or reports on an NFS mounted drive. The problem with your /tmp suggestion is that now the forms/ reports/queries are not in the current working directory, so ISQL can't find them. Yes I could make a /developer directory on the Informix server and have any developer put their forms/reports/queries there, but that's what I was trying to avoid because it scatters the users' personal files around the enterprise. Or we could just ignore the error message and always set the database with a database SQL command, which works as well. > - > Jonathan Leffler                   #include <disclaimer.h> > Email: jleff...@earthlink.net, jleff...@us.ibm.com > Guardian of DBD::Informix v2007.0914 --http://dbi.perl.org/ Thank you very much for your suggestions.

On Jan 10, 2008 5:07 AM, Mark Conrad <mac@pt.com> wrote: > On Jan 9, 12:01am, Jonathan Leffler <jleff...@earthlink.net> 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. > > I'm not so suire about that. My ancient 7.20 installation on Solaris > (8+ year old installation) either doesn't look in the current working > directory first, or doesn't care that it's NFS mounted. It finds the > databases on the locally mounted DBPATH, and the forms/reports/queries > in the NFS mounted current working directory. Hmmm...OK; I sit here corrected. However, it might be that there was a 'bug' introduced at about this point such that it didn't look in the current directory - and you acclimatized your code to that. Or I could simply be misremembering. It could be a faulty memory. If so, then you appear to have a change of behaviour between releases - and unless it is documented in release notes, it would probably count as a bug. > > > 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? > > The trouble is that ISQL is looking in the current working directory > before DBPATH. I agree, nobody should be accessing a database over > NFS. > > > 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. > > ISQL does allow you to access forms or reports on an NFS mounted > drive. The problem with your /tmp suggestion is that now the forms/ > reports/queries are not in the current working directory, so ISQL > can't find them. Yes I could make a /developer directory on the > Informix server and have any developer put their forms/reports/queries > there, but that's what I was trying to avoid because it scatters the > users' personal files around the enterprise. Or we could just ignore > the error message and always set the database with a database SQL > command, which works as well. Or you could add the original current directory to DBPATHm perhaps? Or I could stop trying to rescure code that was presented at least partly tongue-in-cheek as there are a variety of issues with it, such as the one you mention. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/ NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.