Re: Pathname for SPERFORM

Here I go inadvertently stirring the soup again. walt@mathcs.emory.edu (Walt Hultgren {rmy}) writes: >In article <dennisp.777654982@infmx> dennisp@informix.com (Dennis Pimple) >writes: >> >>Just to clarify a bit: sperform and sacego will look in current >>directory first, then in each directory of DBPATH for the appropriate >>.frm/.arc file. >I just verified that this is indeed the case under ISQL 4.11.UC1 and >SE 5.01.UC1. I'm usually pretty good about reading all documentation, but >I confess that I missed this point. I guess I assumed that since the >environment variable was named *PATH, it would act like the shell's PATH. >What's the rationale behind initially ignoring DBPATH? Am I correct in >assuming that if I inadvertently cd to the parent directory of my production >database, I will be working against it even though DBPATH contains only the >absolute pathname(s) of my test directory structure? Yes, since the rule includes looking for SE *.dbs directories (a database named foo in the current directory will be used instead of $DBPATH/foo.dbs). This is a bit less of a concern in OnLine, since the database is based on TBCONFIG, regardless of DBPATH. I never gave the issue much thought, but find it workable, because what it allows me to do as a developer is pull a form and 4gl code into my current directory, change and recompile it, test it without changing any environment parameters, then moving .4gi and .frm into wherever and $DBPATH, and the fix is turned up for my users. I trust myself as a developer more than I trust the users to be in the "correct" directory (only slightly, though). >I suggest that a better approach would be to use the current directory if >DBPATH is not set, or use *only* DBPATH exactly as set if it is non-null. You may be right, but I imagine this would be difficult to persuade Informix to change at this point, because of the old "breaking legacy procedures" justification. I can see a *lot* of shells and c startup routines that would break if the procedure where to be changed. >Is anyone making specific use of the fact that the current directory is >always checked regardless of DBPATH's value? Yes. Longwindedly: Suppose you had a shell that set DBPATH to the directory where common forms are kept, and in which contains a "generic" version of foo.dbs. If a user needed a more "specific" version of the foo database, it was available for them under their home direcorty. Thus, changing performance of how/when $DBPATH was read makes this scheme obsolete, and we get a bunch of flames from folks who set things up this way. It wasn't uncommon for me in my old USWEST/SE days (<-sigh->) to set up a bunch of seperated databases with the exact same schema for different work groups, all working against the same 4gl compiled code and perform screens, with just this sort of approach. ======================================================================= Dennis J. Pimple dennisp@informix.com Opinions expressed Senior Consultant -------------------- are mine, and do not Informix Software Inc Voice: 303-850-0210 necessarily reflect Denver Colorado USA Fax: 303-779-4025 those of my employer.